データ同期プロトコル

专利摘要:
クライアント装置とサーバーとの間でデータを同期させる技術及びシステムを提供する。データを同期させることは、１つ以上のデータクラスの各々に対してクライアント装置とサーバーとの間で同期モードをネゴシエーションすることにより同期セッションを開始することを含む。ネゴシエーションの結果に基づいて状態コードが発生される。発生された状態コードに基づき、クライアント装置及びサーバーは、各データクラスに対してネゴシエーションされた同期モードを使用して１つ以上のデータクラスに対して更新されるべき１つ以上のデータアイテムを交換する。交換された１つ以上のデータアイテムは、クライアント装置又はサーバーにおいて更新される。その更新された１つ以上のデータアイテムは、クライアント又はサーバーにおいてコミットされる。ａ
公开号:JP2011514602A
申请号:JP2010549823
申请日:2009-03-03
公开日:2011-05-06
发明作者:カールステン グンサー；ブレンダン；エイ マッカーシー
申请人:アップル インコーポレイテッド；
IPC主号:G06F12-00

专利说明:

[0001] 本発明は、データ同期のためのプロトコルに係る。]
背景技術

[0002] クライアントとサーバーとの間の同期は、オープンモバイルアライアンス−データ同期プロトコルＯＭＡ ＤＣ／ＳｙｎｃＭＬ（以前はＳｙｎｃＭＬプロトコルとして知られている）のような同期プロトコルを使用して遂行することができる。ＯＭＳ ＤＡ／ＳｙｎｃＭＬは、データクラスのシリアル同期を可能にし、データクラス当たり５つ以上のラウンドトリップを必要とする同期プロトコルである。]
[0003] とりわけ、クライアント装置とサーバーとの間でデータを同期するための技術及びシステムを開示する。]
[0004] １つの態様において、データを同期することは、同期セッションを開始する要求を受け取ることを含む。この要求は、１つ以上のデータクラスの各々に対する提案された同期モードと、１つ以上のデータクラスへの１つ以上の変化とを含む。各データクラスに対する提案された同期モードが受け容れられるかどうか指示するための１つ以上の状態コードが発生される。発生された状態コードに基づき、各データクラスに対して受け容れられた同期モードを使用して、１つ以上のデータクラスへの１つ以上の変化に関連した１つ以上のデータアイテムを選択的に更新する。更新された１つ以上のデータアイテムは、サーバーにおいて選択的にコミットされる。]
[0005] 実施形態は、次の特徴の１つ以上を任意に含むことができる。１つ以上の状態コードを発生することは、以前の同期セッションからセーブされた情報にアクセスして、１つ以上のデータアイテムを同期するのにその提案された同期モードを使用すべきかどうか決定することを含む。要求を受け取ることは、２つ以上のデータクラスに対する提案された同期モードをパラレルに受け取ることを含む。又、要求を受け取ることは、高速同期モード、低速同期モード又はリセット同期モードを含む提案された同期モードを受け取ることを含む。更に、要求を受け取ることは、更新されるべきデータアイテムの交換だけを可能にする高速同期モードを受け取ることを含む。同期セッションは、２つのメッセージを含む１つのラウンドトリップで完了する。同期セッションが中断すると、高速同期を再受け容れすることができる。提案された同期モード、及び１つ以上のデータクラスへの１つ以上の変化は、クライアント装置からの単一のメッセージで受け取ることができる。更新された１つ以上のデータアイテムは、その更新された１つ以上のデータアイテムをコミットするコマンドをクライアント装置が送信するときに、サーバーにおいて選択的にコミットされる。更に、提案された同期モードを拒絶し、又、受け取った要求に、異なる同期モードで応答することができる。]
[0006] 別の態様において、コンピュータ読み取り可能な媒体上で実施されるコンピュータプログラム製品は、データ処理装置が種々のオペレーションを遂行するようにさせるよう動作できる。又、コンピュータプログラム製品は、データ処理装置が同期セッションを開始する要求を受け取るようにさせるよう動作できる。その要求は、１つ以上のデータクラスの各々に対する提案された同期モードと、１つ以上のデータクラスへの１つ以上の変化とを含む。コンピュータプログラム製品は、各データクラスに対する提案された同期モードが受け容れられるかどうかを表す状態コードをデータ処理装置が発生するようにさせるよう動作できる。コンピュータプログラム製品は、データ処理装置が、その発生された状態コードに基づき、各データクラスに対する受け容れられた同期モードを使用して、１つ以上のデータクラスへの１つ以上の変化に関連した１つ以上のデータアイテムを選択的に更新するようにさせるよう動作できる。更に、コンピュータプログラム製品は、データ処理装置が、その更新された１つ以上のデータアイテムをサーバーにおいて選択的にコミットするようにさせるよう構成される。]
[0007] 実施形態は、次の特徴の１つ以上を任意に含むことができる。コンピュータプログラム製品は、データ処理装置が、以前の同期セッションからセーブされた情報に基づいて１つ以上の状態コードを発生するようにさせることができる。又、コンピュータプログラム製品は、データ処理装置が、２つ以上のデータクラスに対する提案された同期モードをパラレルに受け取るようにさせることができる。コンピュータプログラム製品は、データ処理装置が、高速同期モード、低速同期モード又はリセット同期モードを含む提案された同期モードを受け取るようにさせることができる。コンピュータプログラム製品は、データ処理装置が、更新されるべきデータアイテムの交換のみを可能にする高速同期モードを受け取るようにさせることができる。データアイテムの更新オペレーションは、（１）新たなアイテムを生成し（追加）、（２）既存のアイテムの特性を変更し（変更）、又は（３）既存のアイテムを削除する（削除）。又、コンピュータプログラム製品は、データ処理装置が、２つのメッセージを含む１つのラウンドトリップで同期セッションを完了するようにさせることができる。コンピュータプログラム製品は、データ処理装置が同期セッションの中断時に高速同期モードを再受け容れするようにさせることができる。コンピュータプログラム製品は、データ処理装置が、提案された同期モード及び１つ以上のデータクラスへの１つ以上の変化を単一のメッセージで受け取るようにさせることができる。コンピュータプログラム製品は、データ処理装置が、更新された１つ以上のデータアイテムをコミットするコマンドをクライアント装置が送信するときに、更新された１つ以上のデータアイテムをサーバーにおいて選択的にコミットするようにさせることができる。更に、コンピュータプログラム製品は、データ処理装置が、提案された同期モードを拒絶し、及び受け取った要求に異なる同期モードで応答するようにさせることができる。]
[0008] 更に別の態様において、データを同期するためのサーバーは、１つ以上のクライアント装置への１つ以上の接続をオープンすることのできるトランスポートプロトコルを動作するように構成されたプロセッサを備えている。又、プロセッサは、そのオープンされた１つ以上の接続を経てサーバーと１つ以上のクライアント装置との間のデータ同期を可能にする同期プロトコルを動作するようにも構成される。この同期プロトコルは、サーバーが同期セッションを開始する要求を受け取れるようにする。この要求は、１つ以上のデータクラスの各々に対する提案された同期モードと、１つ以上のデータクラスへの１つ以上の変化とを含む。又、同期サーバーは、各データクラスに対する提案された同期モードが受け容れられるかどうか指示するための１つ以上の状態コードをサーバーが発生できるようにする。又、同期プロトコルは、サーバーが、その発生された状態コードに基づいて、各データベースに対する受け容れられた同期モードを使用して、１つ以上のデータクラスへの１つ以上の変化に関連した１つ以上のデータアイテムを選択的に更新きるようにする。更に、同期プロトコルは、更新された１つ以上のデータアイテムをサーバーにおいて選択的にコミットできるようにする。]
[0009] 実施形態は、次の特徴の１つ以上を任意に含むことができる。プロセッサは、受け取られた１つ以上の変化に基づいて１つ以上のデータアイテムを更新するためにデータレポジトリーにアクセスするように構成される。プロセッサは、各データクラスに対する提案された同期モードを、以前の同期セッションからセーブされた情報に基づいて受け容れ又は拒絶するように同期プロトコルを動作するよう構成される。プロセッサは、２つ以上のデータクラスに対する提案された同期モードをパラレルに受け取るように同期プロトコルを動作するよう構成される。又、プロセッサは、高速同期モード、低速同期モード又はリセット同期モードを含む提案された同期モードを受け取るように同期プロトコルを動作するよう構成される。プロセッサは、更新されるべきデータアイテムだけを１つ以上のクライアント装置が送信できるようにする高速同期モードを含む提案された同期モードを受け取るように同期プロトコルを動作するよう構成される。プロセッサは、同期セッションが中断されたときに高速同期を再開する要求を受け取るように同期プロトコルを動作するよう構成される。プロセッサは、２つのメッセージを含む１つのラウンドトリップで同期セッションを完了するように同期プロトコルを動作するよう構成される。プロセッサは、提案された同期モード及び１つ以上のデータクラスへの１つ以上の変化を、１つ以上のクライアント装置のうちの少なくとも１つからの単一メッセージで受け取るように、同期プロトコルを動作するよう構成される。プロセッサは、１つ以上のクライアント装置のうちの１つが、更新された１つ以上のデータアイテムをコミットするコマンドを送信するときに、更新された１つ以上のデータアイテムをサーバーにおいて選択的にコミットするように、同期プロトコルを動作するよう構成される。更に、プロセッサは、提案された同期モードを拒絶し、及び異なる同期モードで要求に応答するように、同期プロトコルを動作するよう構成される。]
[0010] 更に別の態様において、データを同期することは、同期セッションを開始するためにサーバーへ要求を送信することを含む。その要求は、１つ以上のデータクラスの各々に対する提案された同期モードと、１つ以上のデータクラスへの１つ以上の変化とを含む。各データクラスに対する提案された同期モードがサーバーにより受け容れられたかどうか指示するために１つ以上の同期コードが受け取られる。その受け取られた状態コードに基づいて、各データクラスに対する受け容れられた同期モードを使用して、１つ以上のデータクラスへの付加的な変化をサーバーから受け取る。更に、クライアント装置において、サーバーから受け取られた付加的な変化がコミットされる。]
[0011] 実施形態は、次の特徴の１つ以上を任意に含むことができる。１つ以上の状態コードは、１つ以上のデータクラスのうちの少なくとも１つに対する提案された同期モードがサーバーにより拒絶されたかどうか指示することができる。拒絶された同期モードとは異なる同期モードを含む別の要求がサーバーへ送信される。又、提案された同期モード及び１つ以上の変化は、単一のメッセージにおいてサーバーへ送信される。２つ以上のデータクラスに対する提案された同期モードは、パラレルに送信される。更に、２つ以上のデータクラスの各々に対して異なる提案された同期モードがパラレルに送信される。例えば、１つのデータクラスに対して提案された高速同期モードを送信し、そして別のデータクラスに対して提案された低速同期モードを送信することができる。同期セッションが中断された後に、受け容れられた同期プロトコルを使用して同期セッションが再開される。]
[0012] 更に別の態様において、コンピュータ読み取り可能な媒体上で実施されるコンピュータプログラム製品は、データ処理装置が１つ以上のオペレーションを遂行するようにさせるよう動作できる。又、コンピュータプログラム製品は、データ処理装置が同期セッションを開始する要求をサーバーへ送信するようにさせるよう動作できる。その要求は、１つ以上のデータクラスの各々に対する提案された同期モードと、１つ以上のデータクラスへの１つ以上の変化とを含む。コンピュータプログラム製品は、各データクラスに対する提案された同期モードがサーバーにより受け容れられるかどうかを表す１つ以上の状態コードをデータ処理装置が受け取るようにさせるよう動作できる。受け取った状態コードに基づいて、コンピュータプログラム製品は、受け容れられた同期モードを使用して、１つ以上のデータクラスへの付加的な変化をサーバーから受け取り、そしてサーバーから受け取ったその付加的な変化をクライアント装置においてコミットするように動作できる。]
[0013] 実施形態は、次の特徴の１つ以上を任意に含むことができる。コンピュータプログラム製品は、データ処理装置が、１つ以上のデータクラスのうちの少なくとも１つに対する提案された同期モードがサーバーにより拒絶されたことを指示する１つ以上の状態コードを受け取ること及びその拒絶された同期モードとは異なる同期モードを含む別の要求を送信することを含むオペレーションを遂行するようにさせるよう動作できる。コンピュータプログラム製品は、データ処理装置が、提案された同期モード及び１つ以上の変化を単一のメッセージにおいてサーバーへ送信するようにさせるよう動作できる。コンピュータプログラム製品は、データ処理装置が、２つ以上のデータクラスに対する提案された同期モードをパラレルに送信するようにさせるよう動作できる。コンピュータプログラム製品は、データ処理装置が、２つ以上のデータクラスの各々に対する異なる提案された同期モードをパラレルに送信するようにさせるよう動作できる。コンピュータプログラム製品は、データ処理装置が、１つのデータクラスに対して提案された高速同期モードをそして別のデータクラスに対して提案された低速同期モードを送信させるよう動作できる。コンピュータプログラム製品は、データ処理装置が、同期セッションが中断された後に、受け容れられた同期プロトコルを使用して同期セッションを再開するようにさせるよう動作できる。]
[0014] 更に別の態様において、クライアント装置は、サーバーへの１つ以上の接続をオープンすることのできるトランスポートプロトコル、及びそのオープンされた１つ以上の接続を経てクライアント装置とサーバーとの間のデータ同期を可能にする同期プロトコルを動作するように構成されたプロセッサを備えている。同期プロトコルは、クライアント装置が、同期セッションを開始する要求をサーバーへ送信できるようにする。その要求は、１つ以上のデータクラスの各々に対する提案された同期モードと、１つ以上のデータクラスへの１つ以上の変化とを含む。又、同期プロトコルは、クライアント装置が、各データクラスに対する提案された同期モードがサーバーによって受け容れられたかどうかを表す１つ以上の状態コードを受け取ることができるようにする。その受け取った状態コードに基づいて、同期プロトコルは、クライアント装置が、その受け容れられた同期モードを使用して、１つ以上のデータクラスへの付加的な変化をサーバーから受け取ることができるようにする。更に、同期プロトコルは、クライアント装置が、サーバーから受け取った付加的な変化をクライアント装置においてコミットできるようにする。]
[0015] 実施形態は、次の特徴の１つ以上を任意に含むことができる。プロセッサは、１つ以上のデータクラスのうちの少なくとも１つに対する提案された同期モードがサーバーにより拒絶されたことを指示する１つ以上の状態コードを受け取り、そしてその拒絶された同期モードとは異なる同期モードを含む別の要求を送信するように、同期プロトコルを動作するよう構成される。プロセッサは、提案された同期モード及び１つ以上の変化を単一のメッセージにおいてサーバーへ送信するように同期プロトコルを動作するよう構成される。プロセッサは、２つ以上のデータクラスに対する提案された同期モードをパラレルに送信するように同期プロトコルを動作するよう構成される。プロセッサは、２つ以上のデータクラスの各々に対して異なる提案された同期モードをパラレルに送信することを含めて、２つ以上のデータクラスに対する提案された同期モードをパラレルに送信するように同期プロトコルを動作するよう構成される。プロセッサは、１つのデータクラスに対して提案された高速同期モードをそして別のデータクラスに対して提案された低速同期モードを送信するように同期プロトコルを動作するよう構成される。プロセッサは、同期セッションが中断された後に、受け容れられた同期プロトコルを使用して同期セッションを再開するように同期プロトコルを動作するよう構成される。]
発明の効果

[0016] 本発明による技術及びシステムは、潜在的に種々の効果を発揮するように実施することができる。ここに述べる同期プロトコルは、同期セッションを完了するためのラウンドトリップの数（交換される前後のメッセージの数）を減少することができる。ここに述べる同期プロトコルは、例えば、１つのラウンドトリップで同期セッションを完了することができる。ここに述べる同期プロトコルは、複数のデータクラスの各々に対する同期モードネゴシエーションをパラレルに行えるようにする。従って、複数のデータクラスに対する同期モードネゴシエーションの要求を１つのメッセージにおいて送信することができる。更に、ここに述べる同期プロトコルは、フィールドレベル区別及びレコードレベル区別を行えるようにする。]
[0017] ここに述べる同期プロトコルは、ＳｙｎｃＭＬのような従来のプロトコルより簡単である。同期プロトコルに対して利用できるコマンドのセットは、簡単であり、しかも、拡張可能である。ＳｙｎｃＭＬとは異なり、ここに述べる同期プロトコルは、各メッセージをテキスト又はバイナリープロパティリストファイル（ｐｌｉｓｔ）として表す。更に、ここに述べる同期プロトコルは、効率的であり、且つ頑健である。例えば、精巧なアンカーロジックがサーバーに設けられる。更に、同期プロトコルは、信頼性のないネットワークに寛容である。ネットワーク接続が中断したときでも、アンカーロジックは、いったん接続されると、効率的な同期を確保する。更に、同期プロトコルは、比較的小さなメッセージサイズを維持することができる。]
[0018] ここに述べる同期プロトコルは、リッチである。例えば、同期プロトコルは、クライアント装置とサーバーとの間で装置情報を交換することができる。又、同期プロトコルは、便利で、しかも、リッチなデータ表現を与える。]
図面の簡単な説明

[0019] クライアント装置とサーバーとの間でデータを同期できるようにするシステムを示すブロック図である。
サーバーの規範的コンポーネントを示す。
クライアント装置の規範的コンポーネントを示す。
メッセージのヘッダエレメントに対する規範的エレメントを示すテーブルである。
規範的プロパティリストファイル（ｐｌｉｓｔ）を示す。
コマンド要求エレメントに対する規範的エレメントを示すテーブルである。
コマンド応答エレメントに対する規範的エレメントを示すテーブルである。
ゲットコマンドに対する規範的パラメータをテーブルである。
ゲットコマンド応答に対するパラメータを例示するテーブルである。
プットコマンドに対する規範的パラメータを示すテーブルである。
プットコマンド応答に対する規範的パラメータを示すテーブルである。
削除コマンドに対する規範的パラメータを示すテーブルである。
削除コマンド応答に対する規範的パラメータを示すテーブルである。
同期スタートコマンドに対する規範的パラメータを示すテーブルである。
同期スタートコマンド応答に対する規範的パラメータを示すテーブルである。
同期変化コマンドに対する規範的パラメータを示すテーブルである。
同期変化コマンド応答に対する規範的パラメータを示すテーブルである。
同期コミットコマンドに対する規範的パラメータを示すテーブルである。
同期コミットコマンド応答に対する規範的パラメータを示すテーブルである。
同期キャンセルコマンドに対する規範的パラメータを示すテーブルである。
同期キャンセルコマンド応答に対する規範的パラメータを示すテーブルである。
規範的状態エレメントを示すテーブルである。
メッセージヘッダ、コマンド、及びコマンド応答に含ませるのに利用できる状態に対する規範的状態コードを示すテーブルである。
セッション又はメッセージの他のコマンドにおける、コマンドの所与の状態を受け取ることの作用を記述するテーブルである。
アンカーエレメントに対する規範的キーを示すテーブルである。
同期セッションの一例を示す。
クライアント装置とサーバーとの間の最適な高速又はリセット同期の一例を示す。
高速又はリセットデータ同期の別の例を示す。
ｉｄｍａｐがセッション１からセッション２のスタート点へ延期された別の規範的データ同期セッションを示す。
低速同期の一例を示す。
複数のデータクラスをパラレルに同期させる一例を示す。
チェックポイントアンカーを使用する規範的同期セッションを示す。
規範的チェックポイントアンカーを示すテーブルである。
ＤｅｖｉｃｅＩｎｆｏエレメントに対する規範的キー値対を規定するテーブルである。
フィルター設定に対する規範的キー値対を示すテーブルである。
プロトコルシンタックスの拡張バッカス・ナウアフォーム（ＡＢＮＦ）記述である。
規範的同期セッションを示す。
リセット同期セッションに対する４つの規範的メッセージの概要を示す。
クライアント装置からサーバーへ送信される規範的メッセージを示す。
クライアント装置からサーバーへ送られる規範的メッセージを示す。
サーバーからクライアント装置へ送られる規範的メッセージを示す。
サーバーからクライアント装置へ送られる規範的メッセージを示す。
サーバーからクライアント装置へ送られる規範的メッセージを示す。
サーバーからクライアント装置へ送られる規範的メッセージを示す。
クライアント装置から送られる規範的メッセージを示す。
クライアント装置から送られる規範的メッセージを示す。
クライアント装置から送られる規範的メッセージを示す。
サーバーから送られる規範的メッセージを示す。
サーバーから送られる規範的メッセージを示す。
高速同期のための２つの規範的メッセージの概要を示す。
高速同期に対しクライアント装置から送られる規範的メッセージを示す。
高速同期に対しクライアント装置から送られる規範的メッセージを示す。
クライアント装置により送られたメッセージに応答してサーバーから送られる規範的メッセージを示す。
クライアント装置により送られたメッセージに応答してサーバーから送られる規範的メッセージを示す。
クライアント装置により送られたメッセージに応答してサーバーから送られる規範的メッセージを示す。
クライアント装置とサーバーを同期させるための規範的プロセスを示す。
クライアント装置とサーバーを同期させるための規範的プロセスを示す。]
実施例

[0020] 添付図面を通じて同じ要素は同じ参照記号及び呼称で示す。]
[0021] クライアント装置とサーバーとの間でオーバー・ジ・エア（ＯＴＡ）同期を可能にするための技術及びシステムを開示する。特に、ワイヤレス構造化データ同期プロトコルは、クライアント装置がサーバーとインターフェイスして種々のデータを同期できるようにする。このようなプロトコルは、例えば、ｉＰｈｏｎｅ（登録商標）のようなハンドヘルド装置とＭａｃ（登録商標）サーバーのようなサーバーとの間でＭａｃ（登録商標）オペレーティングシステムＸ（ＯＳ Ｘ）ＳｙｎｃＳｅｒｖｉｃｅデータを同期させるのに使用できる。]
[0022] ここに述べるＯＴＡ同期プロトコルは、例えば、トランスポートレイヤセキュリティ（ＴＬＳ）を使用して認証及び／又は許可並びにメッセージセキュリティ／暗号化を遂行するための基礎的なネットワークトランスポートに依存している。同期プロトコルは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）トランスポートプロトコル、又は装置とサーバーとの間で同期プロトコルメッセージを交換できる他の同様のトランスポートプロトコルを使用して、これらデータトランスポートを行えるようにする。]
[0023] 同期プロトコルは、ＨＴＴＰトランスポートのようなトランスポートを経てプロトコルメッセージの交換を行えるようにする。トランスポートを経て交換される各メッセージは、ヘッダエレメント及び本体エレメントを含む。本体エレメントは、一連のコマンド及び／又はコマンド応答エレメントを含むことができる。同期プロトコルは、適切な順序付け及びロス検出を保証するために各メッセージ、コマンド及びコマンド応答に独特のラベルを指定する。例えば、ラベルは、メッセージ、コマンド及びコマンド応答を順序付けるために一連の番号を含むことができる。ラベルを使用して、同期プロトコルは、トランスポート（例えば、ＨＴＴＰ）に代わって、たとえネットワークプロトコルがメッセージ順序付けを実施しなくても、適切な順序付け及びロス検出を保証する。]
[0024] 同期プロトコルは、同期マークアップ言語（ＳｙｎｃＭＬ）のような従来のプロトコルより簡単である。同期プロトコルに利用可能なコマンドのセットは、簡単で、しかも、拡張性がある。例えば、リソースを操作するために３つの融通性のあるプリミティブなコマンドを利用できる。更に、データ同期のために４つの「同期」ファミリーコマンドを利用できる。更に、コマンドは、メッセージ境界を横切って分割されてもよい。ＳｙｎｃＭＬとは異なり、ここに述べる同期プロトコルは、各メッセージをテキスト又はバイナリープロパティリストファイル（ｐｌｉｓｔ）として表現する。Ｍａｃ ＯＳ Ｘ Ｃｏｃｏａ、ＮｅＸＴＳＴＥＰ、及びＧＮＵｓｔｅｐプログラミングフレームワークでは、ｐｌｉｓｔは、シリアル化オブジェクトを記憶するファイルである。ｐｌｉｓｔは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）のウインドウズレジストリーのファンクションと同様に、ユーザの設定を記憶するのにしばしば使用される。又、プロパティリストファイルは、バンドル及びアプリケーションに関する情報を記憶するのにも使用される。ｐｌｉｓｔは、ＮＳＰｒｏｐｅｒｔｙＬｉｓｔＳｅｒｉａｌｉｚａｔｉｏｎクラスのような標準的なオペレーティングシステム（ＯＳ）特徴を使用して生成及びパーズするのが容易である。又、ここに述べる同期プロトコルは、簡単な同期ステートマシンを使用する。]
[0025] ここに述べる同期プロトコルは、効率的で且つ頑強である。例えば、精巧なアンカーロジックがサーバーに設けられる。アンカーは、同期状態を追跡するのに使用されるタグ又はラベルである。又、同期プロトコルは、複数のデータクラスをパラレルに同期させることができる。同期プロトコルは、信頼性のないネットワークに寛容である。ネットワーク接続が中断されても、アンカーロジックは、最小のデータ再送信で再接続されると、効率的な同期を保証する。更に、同期プロトコルは、比較的小さなメッセージサイズを維持することができる。]
[0026] ここに述べる同期プロトコルは、リッチである。例えば、同期プロトコルは、クライアント装置とサーバーとの間で装置情報を交換できるようにする。又、同期プロトコルは、便利で、しかも、リッチなデータ表現を与える。]
[0027] 図１ａは、クライアント装置とサーバーとの間のデータ同期を可能にするシステム１００のブロック図である。システム１００は、ネットワーク１５０を経て１つ以上のサーバー１２０とインターフェイスする１つ以上のクライアント装置１１０を備えている。クライアント装置１００は、移動電話１１２、パーソナルデジタルアシスタント（ＰＤＡ）１１４、ハンドヘルドデータ処理装置１１６、等の移動装置を含むことができる。移動電話１１２は、スマートホン及び一体型移動装置、例えば、ｉＰｈｏｎｅ（登録商標）を含む。ハンドヘルドデータ処理装置は、オーディオ再生装置、例えば、ＭＰ３プレーヤ及びｉＰｏｄ（登録商標）装置を含むことができる。] 図１ａ
[0028] クライアント装置１１０は、セキュアなデータ接続を完成するためにＨＴＴＰトランスポートプロトコルのようなトランスポートプロトコルを使用してサーバー１２０とインターフェイスする。トランスポートプロトコルを通して、同期プロトコル１４０は、接続されたクライアント装置１１０とサーバーとの間のデータ同期を可能にする。同期されるデータは、連絡先（例えば、住所及び電話番号）、カレンダー、等の種々のデータクラスを含むことができる。データ同期は、種々のワイヤード及びワイヤレスネットワーク、例えば、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、イーサネット、インターネット、等を含むネットワーク１５０を経て行うことができる。]
[0029] 図１ｂは、サーバー１２０の規範的コンポーネントを示す。サーバー１２０は、他のコンポーネントの中でも、プロセッサ１６０及びメモリ１７０を含むことができる。プロセッサ１６０は、コンピュータプログラムを実行できる中央処理ユニット（ＣＰＵ）又は他のクラスのロジックマシンを含むことができる。メモリは、固定ハードドライブ又は取り外し可能な記憶装置のような不揮発性記憶装置を含むことができる。取り外し可能な記憶装置は、コンパクトフラッシュユニット、ＵＳＢメモリスティック、等を含むことができる。又、メモリ１７０は、種々の形態のランダムアクセスメモリのような揮発性メモリを含むことができる。] 図１ｂ
[0030] プロセッサ１６０は、１つ以上のクライアント装置１１０へのトランスポート接続をオープンするようにトランスポートプロトコル１３０を動作することができる。プロセッサ１６０は、サーバー１２０とクライアント装置１１０との間のデータ同期を可能にするために、そのオープンされたトランスポート接続を経て同期プロトコル１４０を動作することができる。トランスポートプロトコル１３０及び同期プロトコル１４０は、プロセッサ１６０により実行又は動作されるべくメモリ１７０にロードされて実行される。例えば、図２−４４ｂを参照して以下に述べるように、プロセッサ１６０は、同期セッションを開始するための要求をクライアント装置１１０から受け取るように同期プロトコル１４０を動作することができる。] 図２
[0031] 図１ｃは、クライアント装置１１０の規範的コンポーネントを示す。又、クライアント装置１１０は、他のコンポーネントの中でも、プロセッサ１８０及びメモリ１９０を含むことができる。プロセッサ１８０は、コンピュータプログラムを実行できる中央処理ユニット（ＣＰＵ）又は他のクラスのロジックマシンを含むことができる。メモリは、固定ハードドライブ又は取り外し可能な記憶装置のような不揮発性記憶装置を含むことができる。取り外し可能な記憶装置は、コンパクトフラッシュユニット、ＵＳＢメモリスティック、等を含むことができる。又、メモリ１９０は、種々の形態のランダムアクセスメモリのような揮発性メモリを含むこともできる。] 図１ｃ
[0032] プロセッサ１８０は、１つ以上のサーバー１２０へのトランスポート接続をオープンするようにトランスポートプロトコル１３０を動作することができる。プロセッサ１８０は、クライアント装置１１０とサーバー１２０との間のデータ同期を可能にするために、そのオープンされたトランスポート接続を経て同期プロトコル１４０を動作することができる。トランスポートプロトコル１３０及び同期プロトコル１４０は、プロセッサ１６０により実行又は動作されるべくメモリ１９０にロードされて実行される。例えば、図２−４４ｂを参照して以下に述べるように、プロセッサ１８０は、同期セッションを開始するための要求をサーバー１２０へ送信するように同期プロトコル１４０を動作することができる。] 図２
[0033] 同期は、データストアが一貫したものであると分かった最後のとき以来各データストアに生じた変化を周期的に比較することにより２つの個別のデータストア間に一貫性を維持するプロセスである。データストアは、片側にクライアント装置１１０を、そして他側にサーバー１２０を含むことができる。互いに同期をとるために、データストアは、種々の能力を持つように構成される。例えば、各データストアは、必要なときに全てのデータを供給するように構成される。更に、各データストアは、最後の同期のとき以来の変化を識別し供給するように構成される。各データストアは、同期状態に保持されるべきスキーマに合意するように構成される。各データストアは、サポートされたデータ表現に合意するように構成される。各データストアは、同期プリミティブのセマンティック（即ち、追加、更新、削除）に合意するように構成される。更に、各データストアは、データストアの破損を回避するために同期中に問題が生じたときに以前の状態へロールバックするように構成される。]
[0034] 同期されたデータは、関係モデル（Ｅ−Ｒ）に従い、構造化データ形式（エンティティ）の定義をグループ分けする「スキーマ」又は「データクラス」へと分割される。所与のデータクラス内のエンティティは、「関係」を経て互いに参照する。個別のデータクラスにおけるエンティティ間の関係は、禁止され、従って、各データクラスは、他のデータクラスと完全に独立している。ユーザの観点から、データクラスは、個別の専用のアプリケーションから管理されるように見える。例えば、「連絡先」データクラスは、アドレス帳アプリケーションにより主として管理することができ、一方、「カレンダー」データクラスは、カレンダーアプリケーションにより管理することができる。]
[0035] 同期プロトコル１４０は、低速、リセット及び高速を含む種々の同期モードを可能にする。クライアント装置とサーバーが同期する最初のときに、データクラスの全てのデータが、同一と考えられる既存のデータアイテムに「一致」するように交換される。その後の同期オペレーションに対する同期及びネットワーク帯域巾使用を最適化するため、クライアント装置及びサーバーは、その対が同期した最後のとき以来変化したデータだけを交換すればよい。従って、各エンティティ（即ち、クライアント装置又はサーバー）は、どんなローカル変化を他のエンティティに送らねばならないか決定することができる。更に、各エンティティは、「高速」同期を再開できるまでにより多くのデータの交換を必要とする状況が生じたかどうか検出できねばならない。]
[0036] 低速同期モードは、クライアント装置１１０とサーバー１２０が初めて同期するときにその後の相違のみのデータ交換に対する共通基線を確立するために要求される。低速同期中には、クライアント装置１１０がデータクラスの全てのデータをサーバー１２０に送信する。サーバーは、これらのデータアイテムを、サーバー１２０が既に知っているデータアイテムと一致させるよう試みる。適切な「アイデンティティ一致」が行われないと、複写データが生じることになる。次いで、サーバー１２０は、クライアント装置１１０におけるデータアイテム欠落で応答する。]
[0037] リセット同期モードは、サーバーのデータでクライアント装置におけるデータクラスの全データをリセットするのに使用される。これは、データ構造体が装置１１０へプッシュされたとき、或いはサーバー１２０又は装置１１０が装置のローカルデータの崩壊を決定した場合に生じる。装置１１０は、データを送信せず、又、サーバーは、データクラスの完全なデータ構造体で応答する。]
[0038] 高速同期モードは、特に、限定された帯域巾接続を使用するときに、最も効率的なモードである。クライアント装置１１０は、サーバー１２０との最後の同期以来変化したデータのみを送信する。サーバー１２０は、クライアント装置１１０の外部で変化したデータのみで応答する。]
[0039] 同期セッションは、ネゴシエーション、プル、混合、プッシュ及びコミットを含む段階の個別セットに従うことができる。「プル」及び「プッシュ」という語は、サーバープロセスに対して定義することができる。クライアント装置１００は、プル段階中にそのローカル変化をサーバー１２０へ送信し、又、サーバーのプッシュ段階中に更新を受け取る。]
[0040] ネゴシエーション段階中に、両側（クライアント装置１１０及びサーバー１２０）で、以前の同期セッションからの情報を交換して、現在セッションに対してどんな同期モードを使用すると合意するか決定することができる。同期セッションを識別し編成する上で助けとなるように、各同期セッションには「同期アンカー」が指定される。クライアント装置１１０がサーバー１２０と以前に同期していた場合には、クライアント装置１１０は、おそらく、特定の同期モードを期待する。クライアント装置１１０は、サーバー１２０と高速同期できると考えるが、サーバー１２０は、装置をリセットすることを希望する。要求された同期モードが両側で受け容れられるときには、同期がプル段階へ進むことができる。]
[0041] プル段階中に、クライアント装置１１０は、その変化したレコード（又は同期モードが「低速」である場合には、全てのレコード）をサーバー１２０へ送信する。無効変化は、サーバー１２０により拒絶される。]
[0042] 全ての変化が受け取られると、サーバー１２０は、混合段階に入り、データベースにおける保留中の更新をクライアント装置１１０からの変化と合併させる。混合の結果、対立する変化のセットと、更新のセットとが得られ、これをクライアント装置１１０へプッシュしなければならない。サーバー１２０は、発見的アルゴリズムを使用して全ての対立を自動的に解消することができる。ある実施形態では、クライアント装置１１０が幾つかの対立を解消することが望まれる。同期プロトコル１４０は、対立を表現してサーバー１２０からクライアント装置１１０へ伝送することを許すように設計できる。同期プロトコル１４０は、対立をユーザによりクライアント装置上で解消して同期サーバー１２０へ伝送できるように設計できる。]
[0043] プッシュ段階中に、サーバー１２０からの更新は、クライアント装置１１０へ伝送される。全ての更新がクライアント装置１１０により受け取られると、コミット段階に入る。両側（クライアント装置１１０及びサーバー１２０）で同期が成功したことに合意し、それらの現在同期アンカーを持続し、そして交換したデータをそれらの各データストアへコミットする。]
[0044] 同期中の任意の点で、いずれかの側が同期を打ち消すよう判断し、変化をローカルデータストアへロールバックする。キャンセルは、次の事象の１つ以上に応答して明確に行われ、即ち、予想されない又は無効のデータが送信されたとき、同期ステートマシンにおける予想される遷移をたどらないとき、クライアント装置１１０とサーバー１２０との間の通信が中断したとき、又は他の何らかの問題が生じたときに行われる。]
[0045] データの相違は、種々の粒度で同期させることができる。同期データを交換するときには、クライアント装置１１０及びサーバー１２０は、レコードレベル区別（ＲＬＤ）のために各変化したレコードに対する完全なデータを送信する。或いは又、フィールドレベル区別（ＦＬＤ）のために各変化したレコードの変化したフィールドのみを送信することもできる。特に、データレコードが多数のフィールドを含むか、又は連絡先データクラスの映像のような大量のデータを含むときには、ＦＬＤの方がＲＬＤより好ましい。]
[0046] サーバー１２０は、クライアント装置１１０から受け取ったデータのＲＬＤ及びＦＬＤの両表示を動的にサポートすることができる。変化に対するデータ表示は、クライアント装置１１０が所与のデータクラスに対してＲＬＤを使用するか又はＦＬＤを使用するかを指示する。これは、ＦＬＤをサポートするためのメタ情報を維持する複雑さが合理的でないときに最大の融通性でクライアント装置のデータストアを実施できるようにする。]
[0047] ＲＬＤ変化を受け取ると、サーバー１２０は、その変化を、処理、記憶及び通信効率のためにＦＬＤへ内部変換する。サーバー１２０は、ＲＬＤクライアント装置１１０が完全なレコードを送信することを期待する。クライアント装置１１０によりサポートされ且つクライアント装置のデータレコードから欠落したデータフィールドは、クライアント装置１１０によりクリア／削除されたと仮定する。しかしながら、あるデータフィールド例外値が、それら値を送信せずに不変であることを、クライアント装置１１０が指示できるようにするメカニズムを設けることができる。]
[0048] 識別（ＩＤ）マッピングは、別の基本的同期概念である。同期された各データムは、ユニバーサルな独特のレコードＩＤ又はＵＵＩＤを有する。効率のために、サーバー１２０は、ＳｙｎｃＳｅｒｖｉｃｅのＵＵＩＤをＭａｃ ＯＳ Ｘに使用することができる。或いは又、クライアント装置１１０のアプリケーションは、例えば、ローカルなデータストアの効率を促進するために、データに対するそのローカルな独特のＩＤ（ＬＵＩＤ）を使用することができる。]
[0049] サーバー１２０は、クライアント装置１１０のデータストアがそれら自身のＬＵＩＤを使用して、必要に応じてデータアイテムを参照できるようにする。このケースでは、サーバー１２０は、クライアント装置１１０がそれ自身のローカルＩＤを使用することによりグローバルレコードを透過的に参照できるようにするためＬＵＩＤ−ＵＵＩＤマッピングを維持する。サーバー１２０は、データクラスに対して「低速」又は「リセット」同期モードが受け容れられたときに新たなマッピングを再確立する。]
[0050] 同期プロトコル１４０は、ＨＴＴＰのようなトランスポートプロトコル１３０を使用してサーバー１２０と装置１１０との間で交換される一連のメッセージを含む。同期プロトコル１４０は、トランスポートプロトコル１３０で交換されるメッセージを含む。同期プロトコルにおけるクライアント装置１２０及びサーバー１３０の役割は、通信／トランスポートプロトコルにおけるそれらの役割とは異なる。例えば、ＨＴＴＰトランスポート１３０の場合に、装置１１０は、トランスポート１３０に対して常にクライアントであり、従って、装置１１０は、要求しか発しない。しかしながら、同期プロトコル１４０のメッセージプロトコルでは、クライアント装置１１０及びサーバー１２０の両方がメッセージコマンドを互いに発行する。]
[0051] トランスポート
トランスポートプロトコル１３０は、サーバー１２０とクライアント装置１１０との間のメッセージの交換を管理する。トランスポートプロトコル１３０は、ＨＴＴＰトランスポート又は他の適当なトランスポート、例えば、拡張可能なメッセージング及びプレゼンスプロトコル（ＸＭＰＰ）を含むことができる。トランスポートプロトコル１３０のレイヤは、認証を取り扱い、従って、同期プロトコル１４０は、セキュリティ／認証処理を取り扱う必要がない。これは、同期プロトコル１４０がより効率的に機能できるようにし、少数のラウンドトリップしか必要としないようにする。例えば、トランスポートレイヤセキュリティ（ＴＬＳ）は、送信されたデータのセキュリティを必要に応じて保証するのに使用される。又、トランスポートプロトコル１３０は、メッセージチャンキングを遂行することができる。トランスポートプロトコル１３０は、配信又はメッセージ順序付けを保証する必要がない。というのは、同期プロトコル１４０が、それを行ってメッセージロスを検出する必要な情報を有するからである。]
[0052] ＨＴＴＰは、リソースに対して遂行されるべきアクションを指示する８つのメソッド又は「バーブ(verbs)」を定義する。ＨＴＴＰメソッドは、ＨＥＡＤ、ＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥ、ＴＲＡＣＥ、ＯＰＴＩＯＮＳ、及びＣＯＮＮＥＣＴを含む。ＨＴＴＰをトランスポートプロトコル１３０として使用するときは、ＰＯＳＴメソッドを使用すべきである。ＰＯＳＴメソッドは、処理されるべきデータ、例えば、ＨＴＴＰ形態のデータを、識別されたリソースへ提出する。このデータは、要求の本体に含まれる。ＰＯＳＴメソッドの結果、新たなリソースの生成、既存のリソースの更新、又はその両方を生じさせる。]
[0053] 例えば、サーバー１２０は、http://sync.mac.com/otaのようなＵＲＬにおいてＯＴＡ同期サービスを提供できる。テキストｐｌｉｓｔ表示を使用するときには、「コンテンツ−タイプ」ヘッダが“ｔｅｘｔ／ｘｍｌ”でなければならない。バイナリーｐｌｉｓｔ表示を使用するときには、「コンテンツ−タイプ」ヘッダが存在しなければならず、そして「アプリケーション／オクテット−ストリーム」でなければならない。「コンテンツ−長さ」ヘッダは、メッセージのサイズを指示しなければならない。ユーザ−エージェントストリングは、クライアントプロトコル実施を識別するのに使用される。ユーザ−エージェントストリングは、「モバイル／１Ａ５４３」という形式でなければならない。或いは又、デバイスインフォ（Ｄｅｖｉｃｅｉｎｆｏ）メソッドを使用して、デバイス実施バージョンを決定することもできる。]
[0054] ＯＴＡプロトコル構造
セッションは、クライアント装置１１０とサーバー１２０との間で多数のプロトコルメッセージを交換することより成る。ＨＴＴＰトランスポート実施形態は、クッキーを使用して、サーバー１２０とのセッションを維持することができる。メッセージヘッダにおいてフラグをセットすることによってセッションが完了することをクライアント装置１１０又はサーバー１２０のいずれかが指示する。各メッセージは、受信者により処理することのできる一連のコマンドを含む。クライアント装置１１０は、サーバー１２０への接続を開始する当事者として呼称される。]
[0055] 同期プロトコル１４０を使用して交換されるメッセージは、ＵＴＦ−８エンコードＯＳＸプロパティリスト（即ち、ディクショナリー）として表される。この表示は、クライアント装置１１０及びサーバー１２０の両方における生成、シリアル化及びパージングを容易にする。同期プロトコル１４０は、拡張可能なマークアップ言語（ＸＭＬ）及びｐｌｉｓｔのバイナリー表示の両方をサポートすることができる。バイナリーｐｌｉｓｔは、ＸＭＬｐｌｉｓｔより６０％から８０％以上コンパクトにすることができる。ＸＭＬｐｌｉｓｔ表示を使用するときには、送信されるバイナリーデータは、ベース６４エンコード型ＮＳＤａｔａオブジェクトとしてシリアル化され、テキストデータは、ＲＦＣ３０７６に基づいてＸＭＬエスケープされる。各プロトコルメッセージは、２つのルートエレメント、即ちヘッダ及び本体より成る。]
[0056] 図２は、規範的ヘッダエレメント２１０を示すテーブルである。メッセージヘッダエレメント２１０は、ｓｅｒｖｉｃｅ（サービス）、ｄｅｖｉｃｅｉｄ、ｖｅｒｓｉｏｎ（バージョン）、ｕｓｅｒｉｄ、ｓｅｑｕｅｎｃｅ（シーケンス）、ｍｓｉｓｄｎ、ｆｉｎａｌ（最終）、ｒｅｓｕｌｔ（結果）、等を含むことができる。各ヘッダエレメント２１０に対応して、ヘッダエレメントのタイプ２２０も示されている。又、図２は、各ヘッダエレメント２１０が必要かどうかも示す（２３０）。更に、図２には、各ヘッダエレメントの短い記述２４０も示されている。] 図２
[0057] ヘッダエレメント２１０は、メッセージを送信するエンティティ（例えば、クライアント装置１１０又はサーバー１２０）を識別し、そしてあるセッションコントロール情報を含むことができる。ヘッダエレメント２１０は、メッセージの必要なエレメントであり、ヘッダエレメントの値は、ディクショナリーである。ヘッダのエレメント２１０は、例えば、ソースエンティティ（ｄｅｖｉｃｅｉｄ）及びターゲットサービス（ｓｅｒｖｉｃｅ）、ターゲットアカウント（ｕｓｅｒｉｄ）、及びメッセージシーケンスナンバー（ｓｅｑｕｅｎｃｅ）を指示することができる。又、“ｖｅｒｓｉｏｎ”エレメントは、同期プロトコルバージョンが使用されることを指示できる。例えば、図２は、記述２４０の欄に、現在バージョンが“１．０”であることを示している。これらのエレメント２１０は、全て、メッセージに存在しなければならない。] 図２
[0058] 又、図２は、ヘッダエレメント２１０のｓｅｒｖｉｃｅ、ｄｅｖｉｃｅｉｄ、ｖｅｒｓｉｏｎ、ｕｓｅｒｉｄ、ｓｅｑｕｅｎｃｅ、及びｍｓｉｓｄｎの値がストリングとしてセットされることも示している。例えば、ｓｅｑｕｅｎｃｅエレメントの値は、所与のセッションに対して“１”でスタートする単純に増加する整数値である。ｓｅｑｕｅｎｃｅエレメントは、セッションに対するメッセージ順序を指示するのに使用される。] 図２
[0059] ｓｅｒｖｉｃｅエレメントの値は、同期サーバーのようなターゲットサービスの名前を識別するストリングである。ｕｓｅｒｉｄエレメントの値は、メッセージに対するターゲットアカウントを指示するストリングである。ｕｓｅｒｉｄエレメントは、トランスポートレイヤ１３０においてサーバー１２０で認証されるプリンシパルを識別することができる。クライアント装置１１０のｄｅｖｉｃｅｉｄは、装置のハードウェアを独特に識別するストリングである。ｉＰｈｏｎｅ（登録商標）及びｉＰｏｄ（登録商標）タッチ装置の場合に、ｄｅｖｉｃｅｉｄエレメントは、集積回路カード（ＩＣＣＩＤ）値である。又、ＧＳＭ無線を伴うクライアント装置１１０は、現在インストールされた／アクティブなセキュリティインフォメーションマネージメント（ＳＩＭ）カードの電話番号を指示するためにｍｓｉｓｄｎエレメントを送信する。ｍｓｉｓｄｎ値は、例えば、ユーザがＳＩＭカードを交換するとき、同期の振舞いに影響せずに、あるセッションから次のセッションへ変化する。]
[0060] ｆｉｎａｌエレメントは、送信者（例えば、クライアント装置１１０）が、完了されるべきセッションの側を考慮するときにヘッダに存在する。ｆｉｎａｌエレメントは、値が「真」のブーリアンである。ｆｉｎａｌエレメントフラグが存在するときには、セッションが完了であると考えられる。送信者は、次いで、セッション関連リソースを解放し、そして受信者は、別のメッセージを送信することが要求されない。受信者は、未処理のコマンド応答を返送するために別のメッセージを送信する。しかしながら、受信者は、更に別のコマンド要求を送信してはならない。ｕｓｅｒｉｄ及びｓｅｒｖｉｃｅエレメントの値は、所与のセッションの全てのメッセージに対して一定でなければならない。ｄｅｖｉｃｅｉｄエレメントの値は、送信エンティティに対して一定に保たれねばならない。換言すれば、サーバー１２０及びクライアント装置１１０は、異なる値を有してもよいが、これらの値は、変化しない。]
[0061] ｒｅｓｕｌｔエレメントは、メッセージの全体的な状態を指示するためにメッセージのヘッダに存在する。プロトコルの簡潔さのため、ヘッダ状態をもたないメッセージに対してＳ＿ＯＫ状態が示唆される。メッセージが受け容れられなかったことが検出されると、ヘッダにはｒｅｓｕｌｔエレメントが存在する。データが不格好になるか、又は受信者がセッションの致命的状態に遭遇するときは、メッセージが受け容れられない。非ＯＫ状態値は、先行するメッセージ本体が処理されず、メッセージコマンドがいずれも遂行されず、又、セッションを終了しなければならないことを指示する。例えば、Ｅ＿ＢａｄＲｅｑｕｅｓｔ（７０３）のヘッダ状態値は、以前のメッセージが不格好なものであったことを指示する。Ｅ＿ＬｉｍｉｔＥｘｃｅｅｄｅｄ（６１１）のヘッダ状態値は、以前のメッセージサイズが受信者の能力を越えることを指示する。又、Ｅ＿ＳｅｒｖｉｃｅＢｕｓｙ（７００）、Ｅ＿ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅ（７０１）、及びＥ＿ＲｅｔｒｙＬａｔｅｒ（７０４）のヘッダ状態値は、サーバー１２０が、要求を処理する上で困難に遭遇していることを指示する。]
[0062] 図３は、規範的なｐｌｉｓｔ３００を示す。規範的なｐｌｉｓｔ３００は、ヘッダ３１０及び本体３２０を含む。ヘッダ３１０は、種々の規範的ヘッダエレメント３１２、３１４、３１６、３１８及び３１９を含む。例えば、“ｆ１２３４５６７ａ０７４５ａ８９０ａ８６ｂ５５５６ｄ９ｅ０２０２０２ｂＲＸ８”のストリング値を有する規範的ｄｅｖｉｃｅｉｄエレメント３１２が示されている。又、“１４１５５３３８２０７”のストリング値を有する規範的ｍｓｉｓｄｎエレメントも示されている。加えて、“１”の値を有する規範的ｓｅｑｕｅｎｃｅエレメントも示されている。又、ｐｌｉｓｔ３００は、ｓｙｎｃのストリング値をもつ規範的ｓｅｒｖｉｃｅエレメントも含む。更に、ｐｌｉｓｔ３００は、“１．０”のストリング値をもつ規範的ｖｅｒｓｉｏｎエレメントも含む。] 図３
[0063] メッセージの本体は、受信者によって処理されるべきコマンド要求及び／又はコマンド応答のアレイを含む。本体エレメントは、メッセージの必要なエレメントであり、本体の値は、コマンド又はコマンド応答ディクショナリーのアレイとして表される。本体エレメントは、送信者が送信すべきコマンドを有していないときに空である。本体のコマンドは、コマンドシーケンス順序で処理される。]
[0064] 装置１１０及びサーバー１２０は、両方とも、コマンド要求及び応答を同じメッセージ内で送信する。これは、現在セッションの状態に依存する。]
[0065] 同期プロトコルにおけるコマンドは、次の２つの一般的カテゴリーに入る。即ち（１）メッセージ又はセッションにおいて送信者、受信者及び他のコマンドの処理の状態に影響を及ぼすコマンド、並びに（２）そうでないコマンド。所与のステートレス(stateless)コマンドが首尾良く実行されるかどうかは、メッセージにおける他のコマンドに暗示的に影響しない。ステートフル(stateful)コマンドは、「コマンドファミリー」プレフィックス（例えば、全てのデータ同期コマンドに対して“ｓｙｎｃ−”）で始まる。又、コマンドファミリープレフィックスは、サーバー１２０が異なるクライアント装置１１０に対してサービスの任意のセットをサポートできるようにする有用なコマンドｎａｍｅｓｐａｃｅメカニズムも与える。所与のメッセージでは、所与の「コマンドファミリー」におけるコマンドは、シリーズで処理され、いずれかのコマンドが不成功状態を返送する場合は、そのファミリーにおけるその後のコマンドが全く処理されない。例えば、この場合には、コマンドが処理されなかったことを示す状態コード（例えば、Ｅ＿ＣｏｍｍａｎｄＮｏｔＰｒｏｃｅｓｓｅｄ）をもつコマンド応答を返送することができる。]
[0066] 非最終的メッセージの受信者は、各コマンドに対する１つ以上のコマンド応答をセッションの次のメッセージに含ませる。最終的メッセージの受信者は、最終的メッセージがトランスポートレイヤ要求において送信された（即ち、トランスポート応答が予想される）ときに各コマンドに対して１つ以上のコマンド応答を含ませる。最終的メッセージの受信者は、最終的メッセージがトランスポートレイヤ応答において送信されたときに各コマンドに対して１つ以上のコマンド応答を含ませる。]
[0067] 「ゲット(get)」「プット(put)」及び「デリート(delete)」の３つのステートレスプリミティブコマンドを定義することができる。これらのステートレスコマンドは、同期プロトコル１４０内で任意のオブジェクト交換又は表現的状態転送（ＲＥＳＴｆｕｌ）セマンティックを実施するのに使用される。これは、サーバー１２０がデータ同期オペレーションを遂行することを要求せずに、例えば、マネージメントアクションを遂行し、装置設定又は能力を転送し、或いは大きなバイナリーオブジェクト又は他のメタデータを参照するのに使用できる。]
[0068] 所与のコマンド又はコマンド応答に対するデータが先天的に大き過ぎることが検出されると、送信者は、それを複数の断片に分割して、連続メッセージで送信することができる。所与のコマンドは、メモリの制約、トランスポートの制約、等を含む種々の理由及び／又は制約で分割される。]
[0069] 図４は、コマンド要求に含まれる規範的コマンドエレメントを示すテーブルである。各コマンド要求又はコマンド応答がディクショナリーによって表現される。コマンド要求に対して、種々のコマンドエレメント４１０を設けることができる。規範的コマンドエレメントは、“ｎａｍｅ（名前）”エレメント、“ｓｅｑｕｅｎｃｅ（シーケンス）”エレメント、及び“ｐａｒａｍｓ”エレメントを含む。これらのコマンドエレメント４１０は、全てのコマンドに対して存在しなければならない。“ｎａｍｅ”及び“ｓｅｑｕｅｎｃｅ”エレメントに対する値４２０は、ストリングである。“ｐａｒａｍｓ”エレメントに対する値は、ディクショナリーでなければならない。ディクショナリーは、キー／値対のマップである。特定のコマンドにもよるが、キーは、ストリングであり、値は、他のタイプである。更に、各コマンドエレメントに対して、テーブルの第２の列に値タイプ４２０が示されている。第３の列４３０は、コマンドエレメントが要求されるかどうか指示する。更に、最後の列には、各コマンドエレメントの短い記述４４０が示されている。] 図４
[0070] メッセージと同様に、コマンドは、セッションごとに単調に増加するｓｅｑｕｅｎｃｅエレメントに整数値を指定することができる。例えば、整数値は、“１”でスタートし、セッションごとに単調に増加することができる。ｓｅｑｕｅｎｃｅエレメントの検出された値に基づいて、受信者は、シーケンス順序でコマンドを処理する。]
[0071] ｎａｍｅエレメントは、コマンドの名前を指示する必要なエレメントである。ｎａｍｅエレメントの値は、ストリングである。]
[0072] コマンド要求は、ｐａｒａｍｓエレメントを使用して、コマンドに対するパラメータを受信者へ送る。ｐａｒａｍｓエレメントは、ディクショナリーを含む値を有する必要なエレメントである。特定のパラメータエレメント及び値は、図４に示すように、特定のコマンドに基づいて変化する。] 図４
[0073] ｍｏｒｅエレメントは、コマンドが断片へと分割されることを送信者が指示する必要があるときにコマンドに存在することが要求される。各断片は、オリジナルコマンドの“ｓｅｑｕｅｎｃｅ”値を再使用する。ｍｏｒｅエレメントの値は、それが存在するときは、ブール値「真」である。]
[0074] 図５は、規範的コマンド応答エレメントを示すテーブルである。コマンド応答エレメントは、“ｎａｍｅ（名前）”、“ｓｅｑｕｅｎｃｅ（シーケンス）”、“ｐａｒａｍｓ”、“ｍｏｒｅ（より多く）”、“ｒｅｓｕｌｔ（結果）”及び“ｒｅｓｐｏｎｓｅ（応答）”を含む。各コマンド応答エレメントに対して、値タイプ５２０が設けられる。ｎａｍｅ及びｓｅｑｕｅｎｃｅエレメントの値は、例えば、ストリングである。ｐａｒａｍｓエレメントの値は、ディクショナリーである。ｍｏｒｅ及びｒｅｓｐｏｎｓｅエレメントの値は、ブール値「真」であり、ｒｅｓｕｌｔエレメントの値は、アレイである。] 図５
[0075] テーブルの第３列５３０は、コマンド応答エレメントが必要かどうか示している。更に、コマンド応答ごとに、テーブルの第４列には短い記述５４０が存在する。例えば、ｎａｍｅエレメントは、「ゲット(get)」のようなコマンドの名前を記述する。又、コマンド要求に対応するコマンド応答のためのｓｅｑｕｅｎｃｅエレメントは、同じシーケンス値を親コマンド要求としてもたねばならない。コマンドと同様に、ｐａｒａｍｓエレメントは、コマンド応答に対するパラメータを受信者へ送るためにコマンド応答によって使用される。ｐａｒａｍｓエレメントは、ディクショナリーを含む値を有する必要なエレメントである。特定のパラメータエレメント及び値は、図５に示すように、特定のコマンド応答に基づいて変化する。更に、コマンド応答は、それに関連したコマンド要求と同じパラメータ値を使用する。] 図５
[0076] ｒｅｓｐｏｎｓｅエレメントは、メッセージ本体アイテムがコマンド応答であることを指示する。ｒｅｓｐｏｎｓｅエレメントが存在しないことは、本体がコマンド要求であることを指示する。又、ｒｅｓｐｏｎｓｅエレメントの値は、値「真」をもつブーリアンである。]
[0077] コマンド応答は、整数値が指定されたｓｅｑｕｅｎｃｅエレメントを使用する。上述したように、ｓｅｑｕｅｎｃｅエレメントに指定される値は、受信者により以前に送信されたコマンドシーケンスに対応する。受信者は、コマンド応答をシーケンス値に基づきシーケンス順に処理する。通常、送信者は、所与のメッセージで受け取られたコマンド当たり厳密に１つのコマンド応答を送信する。しかしながら、コマンド応答の状態がＳ＿ＮｏｔＣｏｍｐｌｅｔｅｄ（コマンドの処理がまだ完了していないことを指示する）である場合には、送信者は、コマンドに対する別のコマンド応答をその後のメッセージにおいて送信することができる。或いは又、コマンドが種々の断片へと分割された場合には、コマンド断片当たり１つのコマンド応答が送信される。]
[0078] ｒｅｓｕｌｔエレメントは、コマンド応答に含まれる必要なエレメントである。ｒｅｓｕｌｔエレメントの値は、コマンド要求の結果を指示する１つ以上の状態アイテムのアレイである。コマンドを適時に、例えば、クライアントのトランスポート要求が時間切れする前に、完了できない場合には、受信者は、コマンドが完了されないことを指示するためにＳ＿ＮｏｔＣｏｍｐｌｅｔｅｄ（６０２）のような状態を返送する。この状態は、コマンドの成功又は失敗を指示するものではなく、コマンドの送信者に、セッションにおいて結果が後で得られることを通知する。最終的な状態を受け取る前にセッションが終了するときに、Ｅ＿Ｆａｉｌｅｄ状態のような失敗状態を仮定する。未知のコマンド要求は、Ｅ＿ＵｎｋｎｏｗｎＣｏｍｍａｎｄ（６０８）のような未知の状態値を生じさせる。又、ステートフルコマンドに対する予想しないコマンドは、Ｅ＿ＳｔａｔｅＥｒｒｏｒ（６１０）のような状態エラー値を生じる。]
[0079] 受信者が、ステートフルコマンドを処理する間にエラーに遭遇したときは、メッセージの同じコマンドファミリーに対するその後のステートフルコマンドが全く処理されないことがある。この場合には、コマンドが処理されないことを指示するためにそれらのコマンドに対してＥ＿ＣｏｍｍａｎｄＮｏｔＰｒｏｃｅｓｓｅｄ（６０９）のような状態が返送される。その状態に基づいて、送信者は、それらのコマンドを再試みする。]
[0080] コマンドの定義
図６、７、８、９、１０、１１、１２、１３、１４、１５、１６、１７、１８及び１９は、コマンド及びコマンド定義を例示するテーブルである。同期プロトコル１４０は、同期セッション中に送信するのに使用できるコマンドを定義する。コマンドのこのリストは、包括的リストではない。同期プロトコルを拡大及び拡張して他のサービスを提供するように付加的なコマンドを追加することができる。] 図６
[0081] プリミティブコマンド
図６、７、８、９、１０及び１１にリストされたコマンドは、受信者における任意のリソースを変更することのできるステートレスコマンドである。使用可能なステートレスコマンドは、「ゲット(get)」「プット(put)」及び「デリート(delete)」を含む。これらのステートレスコマンドは、同期プロトコル１４０内におけるオブジェクト交換又はＲＥＳＴｆｕｌセマンティックを実施することができる。各コマンドは、“ｕｒｉ”、“ｖａｌｕｅ”、“ｉｔｅｍ−ｔｙｐｅ”、“ｉｔｅｍｓ”、“ｉｄｍａｐ”、“ｕｓｅｒｉｄ”、“ａｕｔｈｔｙｐｅ”、“ａｕｔｈ”、“ｖｅｒｓｉｏｎ”、“ａｎｃｈｏｒｓ”等を含むことができる。これらパラメータの幾つかが必要とされ、他のものは任意である。] 図６
[0082] 例えば、“ｕｒｉ”パラメータは、ストリング値が指定された必要なパラメータである。“ｕｒｉ”パラメータは、アクセスすべき希望のリソースを指定することができる。同期プロトコル１４０は、“ｕｒｉ”パラメータがクライアント装置１１０の実際のリソースを表すかサーバー１２０の実際のリソースを表すか、例えば、ファイルシステム経路を表すかバーチャルリソースを表すか、指定しない。“ｖａｌｕｅ”パラメータのタイプは、クライアント装置１１０及びサーバー１２０により決定される。更に、“ｖａｌｕｅ”パラメータのタイプは、同期プロトコル１４０によって指定されない。“ｖａｌｕｅ”パラメータの論理的タイプは、“ｉｔｅｍ−ｔｙｐｅ”パラメータを使用して明確に指定することができる。それでも、“ｖａｌｕｅ”パラメータの表現は、有効プロパティリストタイプでなければならない。]
[0083] 受信者は、指示されたＵＲＩへのアクセスを制限する目的で、メッセージの“ｕｓｅｒｉｄ”を許可されたプリンシパルとして使用することができる。セッション許可が不充分である場合には、“ｕｓｅｒｉｄ”、“ａｕｔｈｔｙｐｅ”及び“ａｕｔｈ”エレメントがコマンドに任意に含まれてもよい。]
[0084] 図６は、ｇｅｔコマンドと、“ｕｒｉ”、“ｕｓｅｒｉｄ”、“ａｕｔｈｔｙｐｅ”及び“ａｕｔｈ”を含むその関連パラメータ６１０とを示すテーブルである。これらパラメータの各々にストリング値６２０が指定される。又、テーブルは、どのパラメータが要求されるかも示す（６３０）。ｕｒｉパラメータは要求される（チェックマークで指示された）が、残りのパラメータは、ｇｅｔコマンドと共に任意に含まれる。又、パラメータの記述６４０も設けられる。ｕｒｉパラメータの値は、検索すべきデータオブジェクトのＵＲＩを記述する。任意のｕｓｅｒｉｄパラメータの値は、メッセージのｕｓｅｒｉｄを任意にオーバーライドすべきかどうか記述する。任意のａｕｔｈｔｙｐｅパラメータの値は、任意の認証タイプを記述することができる。任意のａｕｔｈストリングｖａｌｕｅの値は、任意の認証クレデンシャルを記述することができる。] 図６
[0085] 図７は、ｇｅｔコマンド応答に対する規範的パラメータ７１０を示すテーブルである。規範的パラメータは、“ｕｒｉ”、“ｖａｌｕｅ”及び“ｉｔｅｍ−ｔｙｐｅ”を含む。それに関連するパラメータ値７２０は、これらパラメータに対するストリングである。第４列７３０は、ｕｒｉ及びｖａｌｕｅパラメータが要求されるが、ｉｔｅｍ−ｔｙｐｅは任意であることを示す。パラメータの記述７４０も示されている。ｇｅｔコマンドと同様に、ｇｅｔコマンド応答のｕｒｉパラメータは、ｇｅｔコマンドにより要求されるデータオブジェクトのＵＲＩを記述する。ｖａｌｕｅパラメータは、ＵＲＩの値を記述する。例えば、ｇｅｔコマンドは、送信者が希望のデータオブジェクト又は値を受信者から要求することができるようにする。それに応答して、受信者は、ｇｅｔコマンド応答をｇｅｔコマンドの送信者へ送信する。ｇｅｔコマンド応答は、ｇｅｔコマンドにより指示されたＵＲＩに対する結果値を返送するためのｖａｌｕｅパラメータを含む。更に、ｇｅｔコマンド応答に対する任意のｉｔｅｍ−ｔｙｐｅパラメータは、値のタイプを記述する。] 図７
[0086] 図８は、ｐｕｔコマンドの規範的パラメータを示すテーブルである。ｐｕｔコマンドは、送信者が任意のデータオブジェクトを受信者へ転送できるようにする。規範的パラメータ８１０は、“ｕｒｉ”、“ｖａｌｕｅ”、“ｉｔｅｍ−ｔｙｐｅ”、“ｕｓｅｒｉｄ”、“ａｕｔｈｔｙｐｅ”及び“ａｕｔｈ”を含む。このテーブルは、これらパラメータ８１０の各々にストリングパラメータタイプ８２０が指定されることを示す。又、このテーブルは、パラメータが要求されるかどうかも示す（８３０）。例えば、ｕｒｉ及びｖａｌｕｅパラメータは要求されるが、ｒｅｓｔは任意である。最後の列は、各パラメータ８１０の記述８４０を示す。ｕｒｉパラメータの値は、交換すべきデータオブジェクトのＵＲＩを表す。ｖａｌｕｅパラメータは、受信者へプットされるべき値を指定する。ｉｔｅｍ−ｔｙｐｅパラメータは、値の論理的タイプを記述する。任意のｕｓｅｒｉｄパラメータの値は、メッセージのｕｓｅｒｉｄを任意にオーバーライドすべきかどうか記述する。任意のａｕｔｈｔｙｐｅパラメータの値は、任意の認証タイプを記述することができる。任意にａｕｔｈストリングｖａｌｕｅの値は、任意の認証クレデンシャルを記述することができる。] 図８
[0087] 図９は、ｐｕｔコマンド応答に対する規範的パラメータ９１０を示すテーブルである。ｐｕｔコマンドに応答して、受信者は、ｕｒｉパラメータを含むｐｕｔコマンド応答を送信する。ｕｒｉパラメータは、第４列９３０にチェックマークで示されたように必要なパラメータである。パラメータタイプ９２０は、ｕｒｉパラメータに対するストリングである。ｐｕｔコマンドと同様に、ｕｒｉパラメータは、ｐｕｔコマンドに応答して置き換えられたデータオブジェクトのＵＲＩを記述する（９４０）。] 図９
[0088] 図１０は、ｄｅｌｅｔｅコマンドに対する規範的パラメータを示すテーブルである。ｄｅｌｅｔｅコマンドは、“ｕｒｉ”、“ｕｓｅｒｉｄ”、“ａｕｔｈｔｙｐｅ”及び“ａｕｔｈ”のような種々のパラメータ１０１０を含む。パラメータタイプ１０２０は、これらパラメータに対するストリングである。ｕｒｉパラメータは、第４列１０３０にチェックマークで示されたように必要である。残りのパラメータは、任意である。パラメータ１０１０の記述１０４０は、ｇｅｔ及びｐｕｔコマンドについて述べたものと同様である。ｄｅｌｅｔｅコマンドは、送信者が指定のＵＲＩの除去を要求できるようにする。] 図１０
[0089] 図１１は、ｄｅｌｅｔｅコマンド応答に対する規範的パラメータ１１１０を示すテーブルである。ｄｅｌｅｔｅコマンド応答は、ｕｒｉパラメータを含む。このテーブルは、ｕｒｉパラメータタイプ１１２０がストリングであることを示す。ｕｒｉパラメータは必要であり（１１３０）、従って、ｄｅｌｅｔｅコマンド応答に含まれる。又、このテーブルは、パラメータの記述１１４０も含む。例えば、ストリングタイプｕｒｉパラメータは、ｄｅｌｅｔｅコマンドに応答して削除されるオブジェクトのＵＲＩを記述する。] 図１１
[0090] 図１２、１３、１４、１５、１６、１７、１８及び１９にリストされたコマンドは、ステートフルコマンドである。同期プロトコル７０は、ステートフルな同期ファミリーコマンド及びコマンド応答も与える。ステートフルコマンドは、ｓｙｎｃ−ｓｔａｒｔ（同期スタート）、ｓｙｎｃ−ｃｈｅｎｇｅ（同期変更）、ｃｙｎｃ−ｃｏｍｍｉｔ（同期コミット）及びｃｙｎｃ−ｃａｎｃｅｌ（同期キャンセル）を含む。これらのステートフルコマンドは、プロトコルクライアント装置１１０とサーバー１２０との間の構造化データ同期を可能にする。ステートフルコマンド及びコマンド応答の各々は、所与のコマンドにより影響を受けるデータクラスステートマシンを識別するための“ｕｒｉ”パラメータを含む。] 図１２
[0091] 図１２は、ｓｙｎｃ−ｓｔａｒｔコマンドに対する規範的なパラメータ１２１０を示すテーブルである。ｓｙｎｃ−ｓｔａｒｔコマンドは、受信者とで所与のデータクラスに対する同期ステートマシンを生成できるようにする。規範的パラメータ１２１０は、“ｕｒｉ”及び“ａｎｃｈｏｒｓ”を含む。パラメータタイプ１２２０は、ｕｒｉパラメータに対するストリングである。又、パラメータタイプ１２２０は、ａｎｃｈｏｒｓパラメータに対するディクショナリーである。“ｕｒｉ”及び“ａｎｃｈｏｒｓ”パラメータは、第３列１２３０にチェックマークで示されたように必要なパラメータである。] 図１２
[0092] 又、テーブルは、各パラメータに対する記述１２４０も含む。例えば、ｕｒｉパラメータは、連絡先のためのストリング“ｃｏｍ．ａｐｐｌｅ．Ｃｏｎｔａｃｔｓ”又はカレンダーのための“ｃｏｍ．ａｐｐｌｅ．Ｃａｌｅｎｄａｒｓ”のようなデータクラス名を指示する。受信者がデータクラスをサポートしないと検出されたときには、状態Ｅ＿ＮｏｔＳｕｐｐｏｒｔｅｄ（６１２）が返送される。データクラスがイネーブルされないと検出されたときには、状態Ｅ＿ＮｏｔＡｌｌｏｗｅｄ（６０４）が返送される。これら両方の場合には、状態“ｐａｒａｍ−ｎａｍｅ”が存在しければならず、且つｕｒｉパラメータが状態返送の原因であったことを指示するために値“ｕｒｉ”をもたねばならない。ａｎｃｈｏｒｓパラメータは、同期ネゴシエーション段階中に使用される情報を含む。情報は、要求された同期モード（“ｍｏｄｅ”）；データストアバージョン（“ｄｅｖｉｃｅ＿ｖｅｒｓｉｏｎ”、“ｓｅｒｖｅｒ＿ｖｅｒｓｉｏｎ”）；及び同期アンカー（“ｌａｓｔ＿ｄｅｖｉｃｅ＿ａｎｃｈｏｒ”、“ｎｅｘｔ＿ｄｅｖｉｃｅ＿ａｎｃｈｏｒ”、“ｌａｓｔ＿ｓｅｒｖｅｒ＿ａｎｃｈｏｒ”、“ｎｅｘｔ＿ｓｅｒｖｅｒ＿ａｎｃｈｏｒ”）を含むことができる。アンカーエレメントに対する“ｄｅｖｉｃｅ＿ｖｅｒｓｉｏｎ”パラメータは、クライアント装置１１０のバージョンを記述する。アンカーエレメントに対する“ｓｅｒｖｅｒ＿ｖｅｒｓｉｏｎ”パラメータは、サーバープロセス１２０のバージョンを記述する。ａｎｃｈｏｒｓパラメータは、装置、サーバー、フィルター及びリセットアンカーを含む。アンカーは、同期モードを要求するのに使用できる。デフォールト同期モードは、高速同期モードである。アンカーは、同期方向を指定するのに使用できる。デフォールト同期方向は、変更がクライアント装置１１０からサーバープロセス１２０へ並びにサーバープロセス１２０からクライアント装置１１０へ送信されることを指示する“ｔｗｏｗａｙ”である。]
[0093] 図１３は、ｓｙｎｃ−ｓｔａｒｔコマンド応答に対する規範的パラメータを示すテーブルである。ｓｙｎｃ−ｓｔａｒｔコマンド応答に対する規範的なパラメータ１３１０は、“ｕｒｉ”及び“ａｎｃｈｏｒｓ”パラメータを含むことができる。ｕｒｉ及びａｎｃｈｏｒｓパラメータタイプ１３２０は、各々、ストリング及びディクショナリーである。又、テーブルは、これらパラメータが必要なパラメータであるかどうかも示している（１３３０）。テーブルには、パラメータの記述１３４０も示されている。ｕｒｉパラメータは、連絡先、カレンダー、等のデータクラス名を記述する。ａｎｃｈｏｒｓパラメータは、クライアント装置１１０、サーバー１２０、フィルター及びリセットに対して与えることができる。加えて、ａｎｃｈｏｒｓパラメータは、高速、低速及びリセットのような必要な同期モードを指示するのに使用できる。デフォールト同期モードは、高速である。] 図１３
[0094] 受信者は、提出された情報を使用して同期しようとするときには、ＯＫ状態 Ｓ＿ＯＫ（６００）をｓｙｎｃ−ｓｔａｒｔコマンド応答と共に返送する。受信者は、（例えば、クライアントが要求したものとは異なる同期モードを使用して）調整されたパラメータと同期しようとするときには、Ｅ＿ＮｅｇｏｔｉａｔｉｏｎＦａｉｌｅｄ（６１３）のようなネゴシエーション失敗状態を返送する。受信者は、送信者の供給バージョン（例えば、“ｄｅｖｉｃｅ＿ｖｅｒｓｉｏｎ”）をサポートしないとき、バージョンがサポートされないことを指示するＥ＿ＶｅｒｓｉｏｎＮｏｔＳｕｐｐｏｒｔｅｄ（６１２）状態のような状態を返送する。受信者は、希望の同期方向（例えば、“ｄｉｒｅｃｔｉｏｎ”）をサポートしないとき、希望の同期方向がサポートされないことを指示するＥ＿ＮｏｔＳｕｐｐｏｒｔｅｄ（６１４）のような状態を返送する。これら全ての場合に、状態は、コマンドの“ａｎｃｈｏｒｓ”パラメータのエレメントが不成功状態の原因であることを示す値“ａｎｃｈｏｒｓ”と共に“ｐａｒａｍ−ｎａｍｅ”パラメータを含む。更に、受信者は、コマンド応答の“ｐａｒａｍｓ”ディクショナリーに希望の同期モード及びアンカーを指示することができる。]
[0095] クライアント装置１１０は、複数のデータクラスをパラレルに同期させたいときに、図２８に示すように、データクラスごとに個別の“ｓｙｎｃ−ｓｔａｒｔ”コマンド要求を送信する。これらのコマンドは、サーバー１２０が同じ同期ジョブ内のコマンドを処理できるように同じメッセージに含まれる。サーバー１２０がクライアント装置１１０から受け取った“ｓｙｎｃ−ｓｔａｒｔ”コマンドを受け容れると、クライアント装置１１０は、“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドを開始する。既に同期とりをスタートしたセッション中に“ｓｙｎｃ−ｓｔａｒｔ”コマンドを送信することで、Ｅ＿ＳｔａｔｅＥｒｒｏｒ（６１０）状態のようなステートエラー状態が生じる。] 図２８
[0096] 単一のセッションにおいて複数のデータクラスを同期させるときには、データクラスごとのコマンドが個別のステートマシンにおいて動作する。通常、サーバー１２０は、全てのデータクラスがプル段階を完了するか、又は変化したデータを混合する前にキャンセルするまで、待機となる。]
[0097] 図１４は、ｓｙｎｃ−ｃｈａｎｇｅｓコマンドに対する規範的パラメータを示すテーブルである。パラメータ１４１０は、“ｕｒｉ”、“ｉｔｅｍｔｙｐｅ”、“ｉｔｅｍｓ”、“ａｎｃｈｏｒｓ”及び“ｉｄｍａｐ”を含むことができる。ｕｒｉ及びｉｔｅｍｔｙｐｅパラメータに対するパラメータタイプ１４２０は、ストリングである。ａｎｃｈｏｒｓ、ｉｔｅｍｓ及びｉｄｍａｐパラメータに対するパラメータタイプは、ディクショナリーである。テーブルは、第４列１４３０において、ｕｒｉ、ｉｔｅｍｔｙｐｅ及びｉｔｅｍｓパラメータが必要とされるが、ｉｄｍａｐ及びａｎｃｈｏｒｓは任意であることを示している。又、テーブルは、これらパラメータの記述１４４０も含む。ｕｒｉパラメータは、要求された変化についてデータクラスを記述する。ｉｔｅｍｔｙｐｅパラメータは、ｓｙｎｃ−ｃｈａｎｇｅｓコマンドで識別されたアイテム又はデータのタイプを記述する。ｉｔｅｍｓパラメータは、ｉｔｅｍｔｙｐｅに依存するｆｏｒｍａｔ／ｔｙｐｅのようなアイテムのディクショナリーを記述する。ｉｔｅｍｓパラメータに対する関連キーは、装置ｒｅｃｏｒｄｉｄである。ｉｄｍａｐパラメータは、ＧＵＩＤ−ＬＵＩＤ対のディクショナリーを記述する。それに関連するキーは、サーバーｒｅｃｏｒｄｉｄであり、その値は、装置ｒｅｃｏｒｄｉｄである。ａｎｃｈｏｒｓパラメータは、“ｃｈｅｃｋｐｏｉｎｔ ａｎｃｈｏｒ”として含まれる。受信者は、そのアンカーを、その存在時に、供給された値で更新する。セッションが中断されると、受信者は、その後の同期セッションをチェックポイントアンカーでスタートし、低速同期モードに入ることなく通常に同期し続ける。] 図１４
[0098] ｓｙｎｃ−ｃｈａｎｇｅｓコマンドは、クライアント装置１１０がサーバー１２０へ変化を送信できるようにする。或いは又、サーバー１２０は、クライアント装置１１０へ更新を送信することができる。ｕｒｉパラメータは、更新又は変化されるべきデータアイテムのデータクラスを指示する。送信されるデータアイテムのタイプは、ｉｔｅｍｔｙｐｅパラメータにより指示される。ｉｔｅｍｔｙｐｅパラメータは、ｉｔｅｍパラメータが全レコード（“ｒｅｃｏｒｄｓ”）を表すか又はフィールドレベル変化（“ｃｈａｎｇｅｓ”）を表すか指示することができる。クライアント装置１１０がｉｄｍａｐを要求することが検出されると、ｉｔｅｍｓパラメータの装置ＬＵＩＤによってデータアイテムがキーされる。ｉｔｅｍｓパラメータに対するディクショナリーのフォーマットは、ｉｔｅｍ−ｔｙｐｅに依存する。ｉｔｅｍｓパラメータの値は、均質なｉｔｅｍ−ｔｙｐｅである。ｉｔｅｍｓパラメータは、それ以上のアイテムを送信する必要がないことを指示するための空きアレイである。例えば、空きアレイは、変化がないこと、又はレコードがないことを指示できる。]
[0099] 装置変化がないか又は同期モードが「リセット」されたことが検出されると、クライアント装置１１０は、“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドを、“ｉｔｅｍｓ”パラメータに対する空きアレイと共に送信する。データクラスに対する全ての適切なデータアイテムがコマンドパラメータに含まれない場合には、“ｍｏｒｅ”ブーリアンフラグエレメントも含まれる。“ｍｏｒｅ”ブーリアンフラグエレメントは、多量の同期データを小さな塊へと分割するのに使用できる。これは、交換されるべきデータのサイズが受信者の容量より大きいときに有用である。例えば、受信者は、メッセージサイズに限度がある。或いは又、“ｍｏｒｅ”ブーリアンフラグエレメントは、所与のデータクラスに対する複数のｉｔｅｍ−ｔｙｐｅを単一のセッションで交換できるようにする。サーバー１２０がクライアント装置１１０からの全データクラスに対して最後の“ｓｙｎｃ−ｃｈａｎｇｅｓ”塊を受け取ると、サーバー１２０は、供給された全てのデータを中央データベースと同期させる。次いで、プロトコルセッション内のクライアントとサーバーとの役割が逆転される。]
[0100] この点において、クライアント装置１１０は、サーバー１２０からのコマンドの処理を開始する。又、クライアント装置１１０は、サーバー１２０へコマンド応答を返送することができる。サーバーからの同期データ更新は、次いで、“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドにおいて送信される。更新が必要とされない場合には、サーバー１２０は、“ｉｔｅｍｓ”パラメータに対する空きアレイと共に“ｓｙｎｃ−ｃｈａｎｇｅｓ”を送信する。サーバー１２０からの“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンド要求を処理する間に、クライアント装置１１０は、これらのコマンドに応答し、そして“ｉｄｍａｐ”パラメータを使用してコマンド応答の“ｐａｒａｍｓ”に追加トランザクションのための必要なマッピング情報を含ませる。“ｉｄｍａｐ”パラメータは、クライアント装置からの“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドにおいて送信されて、既存のマッピングを送信する。例えば、ｉｄｍａｐは、サーバー１２０がデータエンティティを変化させるのとは独立して更新される。セッション中に“ｓｙｎｃ−ｓｔａｒｔ”の前に或いは“ｓｙｎｃ−ｃｏｍｍｉｔ”又は“ｓｙｎｃ−ｃａｎｃｅｌ”の後に“ｓｙｎｃ−ｃｈａｎｇｅｓ”を送信すると、例えば、Ｅ＿ＳｔａｔｅＥｒｒｏｒ（６１０）状態のようなエラー状態が生じる。装置１００は、“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンド応答の送信を省略し、そしてその後の同期セッションの“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドまで“ｉｄｍａｐ”パラメータの送信を延期させる。これは、同期セッションを完了するのに必要なトランスポートラウンドトリップの数を減少するために行われる。]
[0101] 図１５は、ｓｙｎｃ−ｃｈａｎｇｅｓコマンド応答に対する規範的パラメータを示すテーブルである。パラメータ１５１０は、“ｕｒｉ”、“ａｎｃｈｏｒｓ”及び“ｉｄｍａｐ”を含む。テーブルは、これらパラメータに対するパラメータタイプ１５２０を含む。ｕｒｉパラメータは、ストリングタイプであり、ａｎｃｈｏｒｓ及びｉｄｍａｐパラメータは、ディクショナリーである。又、テーブルは、パラメータが必要であるかどうかの指示も含む（１５３０）。ｕｒｉは、必要であるが、ａｎｃｈｏｒｓ及びｉｄｍａｐパラメータは、任意である。又、テーブルは、これらパラメータの記述１５４０も含む。ｕｒｉパラメータは、必要な変化に対するデータクラスを指示する。ａｎｃｈｏｒｓパラメータは、最後の同期セッションが停止された特定のポイントを指示するのに使用されるチェックポイントアンカーである。ｉｄｍａｐパラメータは、サーバーのｒｅｃｏｒｄｉｄを含むキーを伴うＧＵＩＤ−ＬＵＩＤ対のディクショナリーである。キーの値は、装置ｒｅｃｏｒｄｉｄを含むことができる。] 図１５
[0102] 図１６は、ｓｙｎｃ−ｃｏｍｍｉｔコマンドに対する規範的パラメータを示すテーブルである。ｓｙｎｃ−ｃｏｍｍｉｔコマンドに対するパラメータ１６１０は、“ｕｒｉ”及び“ａｎｃｈｏｒｓ”を含む。ｓｙｎｃ−ｃｏｍｍｉｔコマンドは、同期オペレーションをコミットするのに使用される。このコマンドは、送信者が既にコミットされておりそして受信者もコミットすべきであることを受信者に知らせることを指示する。このテーブルは、パラメータが必要であるかどうか示す（１６３０）。例えば、“ｕｒｉ”パラメータは、必要であるが、ａｎｃｈｏｒｓパラメータは任意である。] 図１６
[0103] 又、このテーブルは、パラメータに対するパラメータタイプ１６２０も示す。ｕｒｉパラメータは、ストリングタイプであり、そしてａｎｃｈｏｒｓパラメータは、ディクショナリーである。又、このテーブルは、パラメータの記述１６４０も示す。ｕｒｉパラメータは、ｓｙｎｃ−ｃｈａｎｇｅｓをコミットするためのデータクラスを指示する。ａｎｃｈｏｒｓパラメータは、サーバー１２０が記憶すべき“ｎｅｘｔ＿ｄｅｖｉｃｅ＿ａｎｃｈｏｒ”を送信するためにクライアント装置１１０により使用される。それに応答して、サーバー１２０は、“ｎｅｘｔ＿ｓｅｒｖｅｒ＿ａｎｃｈｏｒ”をｓｙｎｃ−ｃｏｍｍｉｔコマンドにおいて送信する。更に、次の同期に使用すべき同期モードが指示され、ｓｙｎｃ−ｃｏｍｍｉｔコマンドにおいて返送される。セッション中に最終的な“ｓｙｎｃ−ｃｈａｎｇｅｓ”の前に或いは“ｓｙｎｃ−ｃｏｍｍｉｔ”又は“ｓｙｎｃ−ｃａｎｃｅｌ”の後に“ｓｙｎｃ−ｃｏｍｍｉｔ”コマンドを送信することで、Ｅ＿ＳｔａｔｅＥｒｒｏｒ（６０１）エラー状態のようなエラー状態が生じる。]
[0104] 図１７は、ｓｙｎｃ−ｃｏｍｍｉｔコマンド応答に対する規範的パラメータを示すテーブルである。パラメータ１７１０は、“ｕｒｉ”パラメータを含む。ｕｒｉパラメータに対するパラメータタイプ１７２０は、ストリングである。テーブルの第４列１７３０に示されたように、ｕｒｉパラメータは、ｓｙｎｃ−ｃｏｍｍｉｔコマンド応答に含まれる必要なパラメータである。ｕｒｉパラメータの記述１７４０は、ｕｒｉパラメータが同期セッション中にコミットされるデータクラスを指示することを示している。装置１１０は、同期セッションを完了するのに必要なトランスポートラウンドトリップの数を減少するために“ｓｙｎｃ−ｃｏｍｍｉｔ”コマンド応答の送信を省略する。“ｓｙｎｃ−ｃｏｍｍｉｔ”コマンドにおいて受信された同期アンカーを次のセッションの“ｓｙｎｃ−ｓｔａｒｔ”コマンドにおけるａｎｃｈｏｒｓパラメータとして提出することにより、サーバー１２０は、手前の“ｓｙｎｃ−ｃｏｍｍｉｔ”が受信されたと推論する。] 図１７
[0105] 図１８は、ｓｙｎｃ−ｃａｎｃｅｌコマンドに対する規範的パラメータを示すテーブルである。ｓｙｎｃ−ｃａｎｃｅｌコマンドは、同期オペレーションをキャンセルするのに使用される。ｓｙｎｃ−ｃａｎｃｅｌコマンドは、送信者が既にキャンセルされていて、受信者もキャンセルすべきであることを受信者に知らせることを指示する。受信者は、データクラスに対してそれが行った変化を、最後に受け取った同期アンカーにより表された状態へロールバックしなければならない。このテーブルは、ｓｙｎｃ−ｃａｎｃｅｌコマンドに対するパラメータ１８１０が“ｕｒｉ”パラメータ及びａｎｃｈｏｒｓパラメータを含むことを示す。ｕｒｉパラメータに対するパラメータタイプ１８２０は、ストリングであり、そしてａｎｃｈｏｒｓパラメータは、ディクショナリーである。又、このテーブルは、第４列１８３０に、そのパラメータが必要であるかどうかも示す。ｕｒｉパラメータは、必要であるが、ａｎｃｈｏｒｓパラメータは、任意である。又、このテーブルは、パラメータの記述１８４０も示す。ｕｒｉパラメータは、同期をキャンセルするためのデータクラスを指示する。ａｎｃｈｏｒｓパラメータは、次の同期セッションに対して使用すべきアンカー及び／又は同期モードを指定するのに使用される。セッション中に“ｓｙｎｃ−ｓｔａｒｔ”の前に或いは“ｓｙｎｃ−ｃｏｍｍｉｔ”又は“ｓｙｎｃ−ｃａｎｃｅｌ”の後に“ｓｙｎｃ−ｃａｎｃｅｌ”コマンドを送信することで、Ｅ＿ＳｔａｔｅＥｒｒｏｒ（６１０）エラー状態のようなエラー状態が生じる。装置１１０は、同期セッションを完了するのに必要なトランスポートラウンドトリップの数を減少するために“ｓｙｎｃ−ｃａｎｃｅｌ”コマンド応答の送信を省略する。“ｓｙｎｃ−ｃａｎｃｅｌ”コマンドにおいて受信された同期アンカーを、次のセッションの“ｓｙｎｃ−ｓｔａｒｔ”コマンドにおけるａｎｃｈｏｒｓパラメータとして提出することにより、サーバー１２０は、手前の“ｓｙｎｃ−ｃａｎｃｅｌ”が受け取られたことを推論することができる。] 図１８
[0106] 図１９は、ｓｙｎｃ−ｃａｎｃｅｌコマンド応答に対する規範的パラメータを示すテーブルである。このコマンド応答に使用可能なパラメータ１９１０は、“ｕｒｉ”パラメータである。ｕｒｉパラメータのパラメータタイプ１９２０は、ストリングである。このテーブルは、第４列１９３０に、パラメータが必要であるかどうかも指示する。ｕｒｉパラメータは、チェックマークで指示されたようにコマンド応答に含ませることが要求される。このテーブルは、ｕｒｉパラメータの記述１９４０も含む。ｕｒｉパラメータは、同期をキャンセルするためのデータクラスを指示する。] 図１９
[0107] 状態
図２０は、規範的状態エレメントを示すテーブルである。この規範的状態エレメントは、第１列２０１０に示され、それに対応する値が第２列２０２０に示されている。テーブルの第３列２０３０は、その状態エレメントが必要であるかどうか示している。又、テーブルの最後の列２０４０は、各状態エレメントの短い記述を示す。] 図２０
[0108] 所与のコマンド又はメッセージの処理から生じる状態は、“ｓｔａｔｕｓ（状態）”エレメントにより表される。メッセーズヘッダには、単一の状態エレメントが現れる。メッセージが処理されなかったときには、それに対応する状態エレメントがメッセージヘッダに含まれる。コマンド応答の“ｒｅｓｕｌｔｓ”パラメータには、“ｓｔａｔｕｓ”エレメントのアレイが含まれる。]
[0109] 状態エレメントは、コマンド要求の結果を指示する。状態アイテムは、ディクショナリーである。ディクショナリーは、“ｓｔａｔｕｓ”エレメントを含むと共に、それに対応するコマンド要求の結果状態を指示するために“ｃｏｄｅ”エレメントを含む。“ｓｔａｔｕｓ”エレメントの値は、ストリングである。“ｃｏｄｅ”エレメントの値は、整数ストリング又は整数を含む。“ｄｅｓｃｒｉｐｔｉｏｎ（記述）”エレメントは、コマンドに存在してもよい任意のエレメントである。“ｄｅｓｃｒｉｐｔｉｏｎ”エレメントの値は、ストリングである。“ｄｅｓｃｒｉｐｔｉｏｎ”エレメントは、純粋な情報であり、コマンドの処理に何ら影響しない。]
[0110] “ｐａｒａｍ−ｎａｍｅ”、“ｐａｒａｍ−ｋｅｙ”及び“ｐａｒａｍ−ｉｎｄｅｘ”エレメントが存在してもよい。それらは、あるコマンドに対する多状態応答を与えるのに使用される。“ｐａｒａｍ−ｎａｍｅ”値は、ストリングでなければならず、コマンド要求のどのパラメータにこの状態アイテムが対応しているか指示する。“ｐａｒａｍ−ｉｎｄｅｘ”値は、ストリング又は整数でなければならない。これは、“ｐａｒａｍ−ｎａｍｅ”エレメントが存在し且つコマンド要求におけるその値がアレイであった場合に存在しなければならない。“ｐａｒａｍ−ｉｎｄｅｘ”の値は、この状態アイテムに対応するコマンド要求における“ｐａｒａｍ−ｎａｍｅ”アイテムのインデックスを指示する。インデックス値は、ゼロベースである。“ｐａｒａｍ−ｋｅｙ”値は、ストリングでなければならない。これは、“ｐａｒａｍ−ｎａｍｅ”エレメントが存在し且つコマンド要求におけるその値がディクショナリーであった場合に存在しなければならない。“ｐａｒａｍ−ｋｅｙ”の値は、この状態アイテムに対応するコマンド要求における“ｐａｒａｍ−ｎａｍｅ”アイテムのキーの値を指示する。]
[0111] 又、“ｐａｒａｍ−ｎａｍｅ”、“ｐａｒａｍ−ｋｅｙ”及び“ｐａｒａｍ−ｉｎｄｅｘ”エレメントが存在してもよい。それらは、必要なエレメントではなく、あるコマンドに対する多状態応答を与えるのに使用できる。“ｐａｒａｍ−ｎａｍｅ”状態エレメントの値は、コマンド要求のどのパラメータにこの状態エレメントが対応しているか指示するストリングである。“ｐａｒａｍ−ｉｎｄｅｘ”エレメントの値は、ストリング又は整数のいずれかである。“ｐａｒａｍ−ｎａｍｅ”状態エレメントが存在し、そしてコマンド要求における“ｐａｒａｍ−ｎａｍｅ”状態エレメントの値に一致するパラメータの値がアレイであったときに状態ディクショナリーに“ｐａｒａｍ−ｉｎｄｅｘ”状態エレメントが含まれる。“ｐａｒａｍ−ｉｎｄｅｘ”状態エレメントの値は、その状態エレメントに対応するコマンド要求における“ｐａｒａｍ−ｎａｍｅ”状態エレメントの値に名前が対応するところのパラメータのアレイパラメータアイテムのインデックスを指示する。インデックス状態エレメントの値は、ゼロベースである。“ｐａｒａｍ−ｋｅｙ”エレメントの値は、コマンド要求におけるどのパラメータにこの状態エレメントが対応するか指示するストリングである。“ｐａｒａｍ−ｋｅｙ”状態エレメントの値は、ストリングである。“ｐａｒａｍ−ｋｅｙ”状態エレメントは、“ｐａｒａｍ−ｎａｍｅ”状態エレメントが存在し、且つコマンド要求における“ｐａｒａｍ−ｎａｍｅ”状態エレメントの値に一致するパラメータの値がディクショナリーであったときに状態ディクショナリーに含まれる。“ｐａｒａｍ−ｉｎｄｅｘ”状態エレメントの値は、この状態エレメントに対応するコマンド要求における“ｐａｒａｍ−ｎａｍｅ”状態エレメントの値に名前が対応するところのパラメータのディクショナリーパラメータアイテムのキーを指示する。]
[0112] 状態におけるインデックスは、オリジナルｐａｒａｍがアレイであった場合に状態に生じるｐａｒａｍのインデックスを参照する。インデックスは、ゼロベースからカウントしてスタートする。このゼロベースメカニズムは、状態の希薄なアレイを返送できるようにする。例えば、アレイであるパラメータ“ｉｔｅｍｓ”を有する以下に示すコマンド（“ｅｘａｍｐｌｅｃｏｍｍａｎｄ”と称する）について考える。このコマンドにおける２つ以外の全てのアイテムは良好に形成され、第２及び第５アイテムが（“不良”）値を有すると仮定する。]
[0113] 上述した“ｅｘａｍｐｌｅｃｏｍｍａｎｄ”に対するコマンド応答は、次のように表される。]
[0114] これは、指示されたもの以外の全部が成功であるようにしてコマンドに対して返送されるべき状態が複数あることを示している。しかしながら、（０から続けて、ひいては、コマンドリストの第２アイテムから続けて）インデックス１においてｐａｒａｍ“ｉｔｅｍｓ”に対して供給される値は、不良値である（状態コード６０７）。第５アイテム（インデックス４）についても同じことが言える。このメカニズムは、成功である１つおきのアイテムに対して状態の非報告を可能にする。このメカニズムは、多数のアイテムがサーバーへ送信されて若干が失敗となるだけであるときに帯域巾使用要件を著しく減少することができる。]
[0115] 単一のコマンド応答で複数の状態を返送する必要があるときは、Ｓ＿ＭｕｌｔｉＳｔａｔｕｓ（６０１）のような状態を状態アレイの第１エレメントとして含ませることにより状態の希薄なアレイが表現される。その後の状態エレメントは、パラメータインデックス値と、パラメータタイプがアレイであったところの失敗したパラメータエレメントに対する個別の状態とを指示する。或いは又、その後の状態エレメントは、パラメータキー値と、パラメータタイプがディクショナリーであったところの失敗したパラメータエレメントに対する個別の状態とを指示する。]
[0116] 一般的な状態に対して、状態コードレンジ６００−６９９のようなあるレンジにおける状態コードを予約することができる。又、サーバーにより返送されそして現在セッションの終了を一般的に招くエラーに対して、レンジ７００−７９９のような別のレンジにおける状態コードを予約することができる。]
[0117] 図２１は、コマンド及びコマンド応答に含ませるのに使用可能な状態に対する規範的な状態コードを示すテーブルである。第１列２１１０は、使用可能な状態を記述する。それに関連した状態コードが第２列２１２０に示されている。第３列２１３０は、各状態に対する記述を示す。最後の列２１４０は、各状態に対する親エレメント又はパラメータを示す。] 図２１
[0118] このテーブルは、成功状態及びエラー状態を記述する。図２１に示した例では、“Ｓ＿ＯＫ”状態には、成功を指示するコード６００が指定される。親エレメントは、メッセージヘッダ又はコマンド応答である。他の成功状態は、多値状態での成功を指示するためにコード６０１に指定された“Ｓ＿ＭｕｌｔｉＳｔａｔｕｓ”状態である。親エレメントは、コマンド応答である。] 図２１
[0119] エラー状態は、コマンドに対するコマンド処理がまだ完了しないことを指示するためにコード６０２に指定された“Ｅ＿ＮｏｔＣｏｍｐｌｅｔｅｄ”状態を含む。親エレメントは、コマンド応答である。指示されたデータオブジェクト又はＵＲＩが見つからないことを指示するために“Ｅ＿ＮｏｔＦｏｕｎｄ”エラー状態がコード６０３に指定される。親エレメントは、コマンド応答である。例えば、アクセス権が不充分であることからオペレーションが許されないことを指示するために“Ｅ＿ＮｏｔＡｌｌｏｗｅｄ”エラー状態がコード６０４に指定される。親エレメントは、コマンド応答である。コマンドが必要なパラメータを見失ったことを指示するために“Ｅ＿ＭｉｓｓｉｎｇＰａｒａｍ”エラー状態がコード６０５に指定される。供給されたパラメータが誤ったものであることを指示するために“Ｅ＿ＰａｒａｍＥｒｒｏｒ”エラー状態がコード６０６に指定される。親パラメータは、コマンド応答である。不良値が供給されたことを指示するために“Ｅ＿ＢａｄＶａｌｕｅ”エラー状態がコード６０７に指定される。親パラメータは、メッセージヘッダ又はコマンド応答である。未知のコマンドが発行されて無視されたことを指示するために“Ｅ＿ＵｎｋｎｏｗｎＣｏｍｍａｎｄ”がコード６０８に指定される。親エレメントは、コマンド応答である。手前のコマンド処理のエラーでコマンドが処理されなかったことを指示するために“Ｅ＿ＣｏｍｍａｎｄＮｏｔＰｒｏｃｅｓｓｅｄ”エラー状態がコード６０９に指定される。親エレメントは、コマンド応答である。“Ｅ＿ＳｔａｔｅＥｒｒｏｒ”は、コマンドファミリーの現在ステートマシンに基づき予想されないコマンドが受け取られたことを指示するためにコード６１０に指定されたエラー状態である。親エレメントは、コマンド応答である。非常に多くのアイテムが供給されたことを指示するために“Ｅ＿ＬｉｍｉｔＥｘｃｅｅｄｅｄ”エラー状態がコード６１１に指定される。親エレメントは、コマンド応答である。プロトコル又はコマンドバージョンがサポートされないことを指示するために“Ｅ＿ＶｅｒｓｉｏｎＮｏｔＳｕｐｐｏｒｔｅｄ”エラー状態がコード６１２に指定される。親エレメントは、メッセージヘッダ又はコマンド応答である。同期モードネゴシエーションが失敗したことを指示するために“Ｅ＿ＮｅｇｏｔｉａｔｉｏｎＦａｉｌｅｄ”エラー状態がコード６１３に指定される。親エレメントは、コマンド応答である。非サポート又は非実行オペレーションが試みられたことを指示するために“Ｅ＿ＮｏｔＳｕｐｐｏｒｔｅｄ”エラー状態がコード６１４に指定される。親エレメントは、メッセージヘッダ又はコマンド応答である。一般的な失敗を指示するために“Ｅ＿Ｆａｉｌｅｄ”エラー状態がコード６１５に指定される。親エレメントは、メッセージヘッダ又はコマンド応答である。現在ステートマシンがキャンセルされたことを指示するために“Ｅ＿Ｃａｎｃｅｌｅｄ”エラー状態がコード６１６に指定される。親エレメントは、コマンド応答である。サーバー１２０が非常にビジーであり、メッセージを処理できないことを指示するために、“Ｅ＿ＳｅｒｖｉｃｅＢｕｓｙ”エラー状態がコード７００に指定される。この状態コードは、装置１１０がコマンドを直ちに再試みすべきであることも指示する。親コードは、メッセージヘッダである。サーバー１２０が使用できず、メッセージを処理できないことを指示するために、“Ｅ＿ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅ”エラー状態がコード７０１に指定される。この状態コードは、装置１１０が直ちに再試みすべきであることも指示する。親エレメントは、メッセージヘッダである。サーバー１２０に内部エラーがあることを指示するために“Ｅ＿ＳｅｒｖｉｃｅＥｒｒｏｒ”エラー状態がコード７０２に指定される。親エレメントは、メッセージヘッダ又はコマンド応答である。サーバー１２０がメッセージを理解できないことを指示するために“Ｅ＿ＢａｄＲｅｑｕｅｓｔ”エラー状態がコード７０３に指定される。親エレメントは、メッセージヘッダである。クライアント装置１１０が後で再試みすることをサーバー１２０が要求することを指示するために“Ｅ＿ＲｅｔｒｙＬａｔｅｒ”エラー状態がコード７０４に指定される。親エレメントは、メッセージヘッダである。]
[0120] 図２２は、コマンドに対して所与の状態を受け取ることの作用を示すテーブルである。指示子“Ｃ”は、状態を受け取るコマンドのみについての失敗を指示する。指示子“Ｆ”は、コマンドファミリーのステートマシンの終了を指示する。“ｓｙｎｃ”コマンドに対するステートマシンの終了は、例えば、“ｓｙｎｃ−ｃａｎｃｅｌ”が間もなく来るという指示である。指示子“Ｍ”は、メッセージが処理されなかったことを指示する。指示子“Ｓ”は、セッションが終了することを指示する。] 図２２
[0121] “Ｅ＿ＮｏｔＦｏｕｎｄ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。“Ｅ＿ＮｏｔＡｌｌｏｗｅｄ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。“Ｅ＿ＭｉｓｓｉｎｇＰａｒａｍ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。更に、メッセージは、処理されない。“Ｅ＿ＰａｒａｍＥｒｒｏｒ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。“Ｅ＿ＢａｄＶａｌｕｅ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。更に、メッセージは、処理されない。“Ｅ＿ＵｎｋｎｏｗｎＣｏｍｍａｎｄ”を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。“Ｅ＿ＣｏｍｍａｎｄＮｏｔＰｒｏｃｅｓｓｅｄ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ、ｄｅｌｅｔｅ、ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドの失敗である。“Ｅ＿ＳｔａｔｅＥｒｒｏｒ”エラー状態を受け取る作用は、ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについて、データクラスステートマシンが終了されることである。“Ｅ＿ＬｉｍｉｔＥｘｃｅｅｄｅｄ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。更に、メッセージは、処理されない。“Ｅ＿ＶｅｒｓｉｏｎＮｏｔＳｕｐｐｏｒｔｅｄ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。更に、セッションが終了となる。“Ｅ＿ＮｅｇｏｔｉａｔｉｏｎＦａｉｌｅｄ”エラー状態を受け取る作用は、ｓｙｎｃ−ｓｔａｒｔコマンドの失敗である。“Ｅ＿ＮｏｔＳｕｐｐｏｒｔｅｄ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。“Ｅ＿Ｆａｉｌｅｄ”エラー状態を受け取る作用は、ｇｅｔ、ｐｕｔ及びｄｅｌｅｔｅコマンドの失敗である。ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについては、データクラスステートマシンが終了される。更に、セッションが終了となる。“Ｅ＿Ｃａｎｃｅｌｅｄ”エラー状態を受け取る作用は、ｓｙｎｃ−ｓｔａｒｔ、ｓｙｎｃ−ｃｈａｎｇｅｓ、ｓｙｎｃ−ｃａｎｃｅｌ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドについてデータクラスステートマシンが終了されることである。“Ｅ＿ＳｅｒｖｉｃｅＢｕｓｙ”エラー状態を受け取る作用は、セッションが終了となることである。“Ｅ＿ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅ”エラー状態を受け取る作用は、セッションが終了となることである。“Ｅ＿ＳｅｒｖｉｃｅＥｒｒｏｒ”エラー状態を受け取る作用は、全てのコマンドについてセッションが終了となることである。“Ｅ＿ＢａｄＲｅｑｕｅｓｔ”エラー状態を受け取る作用は、セッションが終了となることである。“Ｅ＿ＲｅｔｒｙＬａｔｅｒ”エラー状態を受け取る作用は、セッションが終了となることである。]
[0122] アンカー
同期モード、同期方向、エージェントバージョン、及び同期アンカーのような同期状態情報が種々の時間に装置とサーバーとの間で交換される。図１２−２０に示されたコマンド及びコマンド応答に含まれる“ａｎｃｈｏｒｓ（アンカー）”エレメントは、この情報を束ねるのに使用される。“ａｎｃｈｏｒｓ”エレメントは、ディクショナリーとして実施される。] 図１２
[0123] 図２３は、アンカーエレメントに対する規範的なキーを示すテーブルである。このテーブルは、同期アンカーキー２３１０、関連キータイプ２３２０、及びキーの記述２３３０を例示する列を含む。“ｍｏｄｅ（モード）”キーは、望ましい又はネゴシエーションされた同期モードを表す。ｍｏｄｅキーは、ａｎｃｈｏｒエレメントに存在するのも任意である。ｍｏｄｅキーの値は、それが存在するときに、ストリングとして実施され、そしてストリング値は、同期モードを表すために「低速」、「高速」又は「リセット」を含む。ｍｏｄｅキーの値が存在しないときは、メッセージの受信者は、値が「高速」であると推測する。従って、送信者により指示されるｍｏｄｅキーの値が存在しないと、受信者は、高速同期モードを仮定する。] 図２３
[0124] “ｄｉｒｅｃｔｉｏｎ（方向）”キーは、望ましい又はネゴシエーションされた同期方向を表す。ｄｉｒｅｃｔｉｏｎキーの値は、ａｎｃｈｏｒｓエレメントに任意に存在することができる。ｄｉｒｅｃｔｉｏｎキーの値は、それが存在するときに、ストリングとして実施され、ストリングの値は、“ｔｏ＿ｓｅｒｖｅｒ”、“ｔｏ＿ｄｅｖｉｃｅ”又は“ｔｗｏｗａｙ”を含むことができる。従って、これらの値は、同期方向を、装置１１０からサーバー１２０へ同期をとるものとして、又はサーバー１２０から装置１１０へ同期をとるものとして、或いはその両方として指示する。ｄｉｒｅｃｔｉｏｎキーの値が存在しないときは、受信者は、値を“ｔｗｏｗａｙ”として推測する。]
[0125] “ｄｅｖｉｃｅ＿ｖｅｒｓｉｏｎ”キーは、装置１１０により送信され、装置データソースエージェントバージョンを表す。ｄｅｖｉｃｅ＿ｖｅｒｓｉｏｎキーの値は、それが存在するときに、ストリングとして実施される。この情報は、装置ソフトウェアの所与のバージョンに特有の振舞い又は能力を推測するためにサーバー１２０により使用することができる。サーバー１２０は、例えば、所与の装置エージェントバージョンでは同期が許されないことを決定できる。]
[0126] “ｓｅｒｖｅｒ＿ｖｅｒｓｉｏｎ”キーは、サーバー１２０により送信され、サーバーのデータソースエージェントバージョンを表す。ｓｅｒｖｅｒ＿ｖｅｒｓｉｏｎキーの値は、それが存在するときに、ストリングとして実施される。この情報は、サーバーソフトウェアの所与のバージョンに特有の振舞い又は能力を推測するために装置１１０によって使用することができる。装置１１０は、例えば、所与のサーバーエージェントバージョンでは同期が許されないことを決定できる。]
[0127] 実際のアンカーは、キー“ｌａｓｔ＿ｄｅｖｉｃｅ＿ａｎｃｈｏｒ”、“ｎｅｘｔ＿ｄｅｖｉｃｅ＿ａｎｃｈｏｒ”、“ｌａｓｔ＿ｓｅｒｖｅｒ＿ａｎｃｈｏｒ”及び“ｎｅｘｔ＿ｓｅｒｖｅｒ＿ａｎｃｈｏｒ”を使用して交換される。これら各キーの値は、“ａｎｃｈｏｒｓ”ディクショナリーに存在することができる。これら各キーの値は、それが存在するときに、ストリングとして実施される。存在しないときには、受信者がキーに対する最後に知られた値を推測する。]
[0128] ａｎｃｈｏｒｓエレメントに対するキーの値は、不透明と考えられ、エンティティは、別のエンティティのａｎｃｈｏｒキーをデコードし又はそこから意味を推測するよう試みてはならない。例えば、クライアント装置は、“ｎｅｘｔ＿ｓｅｒｖｅｒ＿ａｎｃｈｏｒ”又は“ｌａｓｔ＿ｓｅｒｖｅｒ＿ａｎｃｈｏｒ”に関して仮定をしてはならない。]
[0129] 同期プロトコル特徴
クライアント装置１１０が相違（即ち、変化、削除又は新データ）をサーバー１２０へ送信するときに、クライアント装置１１０は、“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドの“ｉｔｅｍ−ｔｙｐｅ”パラメータを経て「レコードレベル差（ＲＬＤ）」が使用されるか「フィールドレベル差（ＦＬＤ）」が使用されるか指示する。“ｉｔｅｍ−ｔｙｐｅ”パラメータの値「変化」は、ＦＬＤを指示するが、値「レコード」は、ＲＬＤを指示する。ＲＬＤをサポートする装置は、特定のデータクラスに対する所与の変化したレコードのための全データセットを送信する。これと対照的に、ＦＬＤをサポートする装置は、データクラスに対するデータセットにおける変化したレコードの変化したプロパティしか送信しない。]
[0130] ＲＬＤの場合に、所与のプロパティが変化せず且つ削除もされないことを指示する“＋**ｎｏ−−ｃｈａｎｇｅ**＋”のような特殊な値をクライアント装置１１０が送信できるようにする最適化がサポートされる。これは、変化しない連絡先映像のような大きなデータアイテムの送信を回避する上で助けとなる。]
[0131] ｉｄｍａｐ
データクラスに対する、例えば、クライアント装置１１０のデータストアが、ｉｄｍａｐの使用を希望することを検出すると、サーバー１２０からの“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドに対してコマンド又はコマンド応答に“ｉｄｍａｐ”パラメータを含ませることができる。“ｉｄｍａｐ”パラメータの値は、サーバーのユニバーサルな独特の識別子（ＵＵＩＤ）をクライアント装置１１０のローカルな独特の識別（ＬＵＩＤ）へとマップするディクショナリーである。その後、サーバー１２０は、クライアント装置１１０のＬＵＩＤを使用してそのマップされたエンティティを参照する。]
[0132] 最適化
分割されたセッションは、ワイヤレス通信に対してメッセージ／パケットロスを生じさせる。同期プロトコル１４０は、「高速」同期から抜け出すことなく、分割されたセッションから回復することができる。分割されたセッションの場合でも「高速」同期を維持することにより、通信ラウンドトリップの数が減少される。ラウンドトリップの数が減少されることで、メッセージ／パケットロスを減少し又は最小とすることができる。]
[0133] 同期プロトコル１４０は、通常の環境でトランスポートメッセージ（ＨＴＴＰ要求／応答ラウンドトリップ）の数を最小にするように設計される。「高速」同期モードに留まる能力は、より少ない量のデータを交換することにより各同期プロセスに対する帯域巾使用及び努力を最小にすることができる。更に、頻繁な高速同期は、装置１１０／サーバー１２０対が互いに著しくドリフトしないことを意味する。換言すれば、装置１１０及びサーバー１２０は、高速同期なしに可能である以上に同期状態に留まる。又、このワイヤレス「トリクル同期」は、優れたユーザ経験を生み出すことができる。]
[0134] ある事象は、高速同期対（例えば、クライアント装置１１０及びサーバー１２０対）が低効率の同期モード（例えば、低速同期モード）を頼りにすることができるようにする。これらの事象は、装置データの崩壊、同期セッションの中断、一貫した同期アンカーへの合意の失敗、データ構造のリセット（例えば、ユーザが別のマシンからのデータクラスに対して完全に新しいデータセットをプッシュしたとき）を含む。同期プロトコル１４０は、悲観的であることを回避し、問題が生じたときに低速同期へ戻る必要性を最小にするか又は排除することができる。]
[0135] 同期プロトコル１４０は、クライアント装置１１０とサーバー１２０との間のデータ同期を最適にするために種々の技術を実施する。例えば、最適化技術は、楽観的ネゴシエーション及びコミットを可能にする同期段階圧縮；複数データクラスステートマシンのパラレル実施；同期アンカーチェックポイントの使用；及びセッションの頑健性を可能にすることを含む。]
[0136] 図２４は、同期セッションの一例を示す。クライアント装置１１０とサーバー１２０との間の同期セッションは、種々のメッセージ２４１０、２４２０、２４３０、２４４０、２４５０及び２４６０を含む。例えば、メッセージ１ ２４１０は、送信者により受信者へ送信される。図２４に示す例では、送信者がクライアント装置１１０であり、受信者がサーバー１２０である。メッセージ１ ２４１０は、同期セッションに対する同期モードをネゴシエートするためにｓｙｎｃ−ｓｔａｒｔコマンドを含む。メッセージ１ ２４１０に応答して、受信者は、ｓｙｎｃ−ｓｔａｒｔコマンド応答のようなコマンド応答を含むメッセージ２ ２４２０を送信する。コマンド応答は、メッセージ１ ２４１０に含まれたコマンドが成功か、失敗か、等を指示するための状態を含む。メッセージ２ ２４２０が終わると、第１ラウンドトリップが完了する。必要に応じて、付加的なメッセージｎ、ｎ＋１、ｎ＋２、等を交換して、同期セッションを完了することができる。同期セッションは、例えば、最終的メッセージｎ＋１を受信すると、終了する。ある実施形態では、付加的な任意のメッセージ２４５０、２４６０、等を交換することができる。] 図２４
[0137] 図２５は、クライアント装置１１０とサーバー１２０との間の最適な高速又はリセットデータ同期の一例を示す。同期段階圧縮は、クライアント装置１１０が個別の同期ステートマシン段階を圧縮できるようにする。例えば、クライアント装置１１０は、おそらく、同期モードが「高速」又は「リセット」になると考えるときに、ネゴシエーション（“ｓｙｎｃ−ｓｔａｒｔ”）及びプル段階コマンド（“ｓｙｎｃ−ｃｈａｎｇｅｓ”）を第１メッセージ２５１０においてサーバー１２０へ送信する。同期段階圧縮は、サーバー１２０が要求された同期モードを拒絶する場合に無駄なネットワークトラフィックを最小にするか又は排除することができる。図２５に示す例では、クライアント装置１１０は、“ｓｙｎｃ−ｓｔａｒｔ”及び“ｓｙｎｃ−ｃｈａｎｇｅ”コマンドを含む第１メッセージ２５１０を送信する。しかしながら、サーバー１２０は、“ｓｙｎｃ−ｃｏｍｍｉｔ”コマンドを第２メッセージ２５２０において送信しない。むしろ、サーバー１２０は、“ｓｙｎｃ−ｓｔａｒｔ”応答、“ｓｙｎｃ−ｃｈａｎｇｅｓ”応答、及び“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドを第２メッセージ２５２０において送信する。第２のラウンドトリップ２５３０において、クライアント装置１１０は、ｓｙｎｃ−ｃｈａｎｇｅ応答及び“ｓｙｎｃ−ｃｏｍｍｉｔ”コマンドを送信する。サーバー１２０は、“ｓｙｎｃ−ｃｏｍｍｉｔ”応答で応答する。] 図２５
[0138] 図２６は、クライアント装置１１０とサーバー１２０との間の最適な高速又はリセット同期の別の例を示す。クライアント装置１１０は、ネゴシエーション（“ｓｙｎｃ−ｓｔａｒｔ”）及びプル段階コマンド（“ｓｙｎｃ−ｃｈａｎｇｅｓ”）を第１メッセージ２６１０においてサーバー１２０へ送信する。ｓｙｎｃ−ｓｔａｒｔネゴシエーションコマンドは、データクラス、アンカー及び同期モードを指示するパラメータを含むことができる。図２６に示す例では、高速同期モードが指示される。] 図２６
[0139] 図２６に示す例において、同期サーバー１２０は、所与のデータクラスに対する“ｓｙｎｃ−ｃｈａｎｇｅｓ”及び“ｓｙｎｃ−ｃｏｍｍｉｔ”コマンドを同じメッセージにおいて送信することにより、プッシュ及びコミット段階を圧縮する。ｓｙｎｃ−ｓｔａｒｔ及びｓｙｎｃ−ｃｈａｎｇｅコマンドに応答して、サーバー１２０は、第２メッセージ２６２０においてｓｙｎｃ−ｓｔａｒｔコマンド応答（ＯＫ、データクラス、アンカー）及びｓｙｎｃ−ｃｈａｎｇｅコマンド応答（ＯＫ、データクラス）で応答する。更に、サーバー１２０は、ｓｙｎｃ−ｃｈａｎｇｅｓコマンド（データクラス、変化）及びｓｙｎｃ−ｃｏｍｍｉｔコマンド（データクラス、アンカー）を第２メッセージ２６２０に含ませて、１つのラウンドトリップを完了させることができる。従って、この楽観的解決策は、単一のＨＴＴＰラウンドトリップでデータ同期を完了させることができる。] 図２６
[0140] クライアント装置１１０が第２メッセージ２６２０におけるサーバー１２０の“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドに対して第２のラウンドトリップ２６３０においてｉｄｍａｐのための任意のメッセージで応答するときには２つのラウンドトリップでデータ同期を完了させることができる。又、クライアント装置１１０は、任意のメッセージにおいてｓｙｎｃ−ｃｏｍｍｉｔ応答を送信することもできる。]
[0141] ある実施形態では、クライアント装置１１０は、サーバー１２０へのｉｄｍａｐの送信をその後のセッションまで延期し、そしてｓｙｎｃ−ｃｏｍｍｉｔ応答の送信を省略する。というのは、サーバー１２０は、コマンドが受け取られ、そしてその後のセッションで送信される同期アンカーと比較することで処理されることを推測できるからである。図２７は、クライアントとサーバーとの間の規範的データ同期を示し、ここで、装置は、サーバーの手前のメッセージが最終的なものであるときに“ｓｙｎｃ−ｃｈａｎｇｅｓ”又は“ｓｙｎｃ−ｃｏｍｍｉｔ”に対するコマンド応答の送信を省略する。この場合に、保留中のｉｄメッセージは、（必要があれば）その後の同期セッションにおいてサーバー１２０へ送信される。] 図２７
[0142] 第１メッセージ２７１０において、クライアント装置１１０は、図２５を参照して述べたように、ネゴシエーション及びプル段階を圧縮する。それに応答して、サーバー１２０は、図２６を参照して述べたようにプッシュ及びコミット段階を圧縮して第２メッセージ２７２０を送信する。第１セッションは、１つのラウンドトリップで完了される。] 図２５ 図２６
[0143] 第３メッセージ２７３０においてプル及びネゴシエーション段階を圧縮してクライアント装置１１０により第２の同期セッションが開始される。更に、第１セッションから先延ばしされた保留中のｉｄｍａｐがサーバー１２０へ送信される。サーバー１２０は、第４メッセージ２７４０において、ｓｙｎｃ−ｃｈａｎｇｅｓ及びｓｙｎｃ−ｃｏｍｍｉｔコマンドで応答する。]
[0144] 図２８は、低速同期の例を示す。クライアント装置１１０は、次の同期モードが「低速」同期モードになると考えるときには、ネゴシエーション及びプル段階を圧縮しない。というのは、その全データセットを初期の要求メッセージ２８１０においてサーバー１２０へ送信することは、例えば、処理コストに関して高価になるからである。更に、サーバー１２０が「リセット」同期モードに対してネゴシエーションしたことを検出すると、データの送信は、帯域巾を浪費することになる。] 図２８
[0145] この低速同期モードでは、クライアント装置１１０は、第１メッセージ２８１０において識別されたデータクラス、アンカー及び低速同期モードでｓｙｎｃ−ｓｔａｒｔコマンドを送信する。サーバー１２０は、第２メッセージ２８２０において、ｓｙｎｃ−ｓｔａｒｔ応答で応答する。第３メッセージ２８３０（第２ラウンドトリップ）では、クライアント装置１１０は、データクラスに対するｓｙｎｃ−ｃｈａｎｇｅｓコマンドを送信する。サーバー１２０は、次のメッセージ２８４０において、ｓｙｎｃ−ｃｈａｎｇｅｓ応答（ＯＫ、データクラス）、ｓｙｎｃ−ｃｈａｎｇｅｓコマンド（データクラス）、及びｓｙｎｃ−ｃｏｍｍｉｔコマンド（データクラス、アンカー）を含ませることにより応答する。第３ラウンドトリップ２８５０では、クライアント装置１１０は、ｓｙｎｃ−ｃｈａｎｇｅｓ応答（ＯＫ、データクラス、ｉｄｍａｐ）及びｓｙｎｃ−ｃｏｍｍｉｔ応答（ＯＫ）を送信する。]
[0146] 図２９は、複数のデータクラスをパラレルに同期させる一例を示す。複数のデータクラスステートマシンをパラレル（並列）に実施することで、複数のデータクラスをパラレルに同期させることができる。全ての“ｓｙｎｃ”ファミリーコマンドにおいて必要な“ｕｒｉ”パラメータにより指定される各データクラスは、それ自身の個別のステートマシンを動作させる。従って、最適なケースでは、全てのデータクラスが単一のトランスポートラウンドトリップにおいて高速同期することができる。比較として、他の同期プロトコル、例えば、オープンモバイルアリアンス−データ同期プロトコル（以前はＳｙｎｃＭＬプロトコルとして知られていた）ＯＭＡ ＤＳ／ＳｙｎｃＭＬは、シリアルに同期し、データクラス当たり５つ以上のラウンドトリップを要求する。] 図２９
[0147] 図２９に示す例では、連絡先、カレンダー及びブックマークのような複数のデータクラスがパラレルに同期される。第１メッセージ２９１０において、クライアント装置１１０は、これらデータクラスに対するｓｙｎｃ−ｓｔａｒｔコマンドをパラレルに送信する。同じメッセージ２９１０において、クライアント装置１１０は、複数のデータクラスに対するｓｙｎｃ−ｃｈａｎｇｅｓコマンドも送信する。サーバー１２０は、複数のデータクラスに対してｓｙｎｃ−ｓｔａｒｔ応答及びｓｙｎｃ−ｃｈａｎｇｅｓ応答を伴う応答２９２０を送信する。例えば、サーバー１２０からのｓｙｎｃ−ｓｔａｒｔ応答は、カレンダーデータクラスがネゴシエーション失敗のためにサーバー１２０においてリセットされることを述べる。更に、カレンダーに対するｓｙｎｃ−ｃｈａｎｇｅｓ応答は、カレンダーのデータクラスに対して変化が処理されなかったことを述べる。連絡先及びブックマークに対するｓｙｎｃ−ｓｔａｒｔコマンドは、ｓｙｎｃ−ｓｔａｒｔ応答のＯＫ状態により示されたように成功である。連絡先及びブックマークに対するｓｙｎｃ−ｃｈａｎｇｅｓコマンドは、ｓｙｎｃ−ｃｈａｎｇｅｓ応答のＳ＿ＮｏｔＣｏｍｐｌｅｔｅｄ状態により示されたように完了していない。] 図２９
[0148] 次のメッセージ２９３０において、クライアント装置１１０は、リセット同期（手前のカレンダーのｓｙｎｃ−ｓｔａｒｔコマンド応答においてサーバーにより要求される同期モード）を要求する別のｓｙｎｃ−ｓｔａｒｔコマンドと、空きアイテムパラメータを伴うカレンダーデータクラスに対するｓｙｎｃ−ｃｈａｎｇｅｓコマンドとを送信する。サーバー１２０は、次のメッセージ２９４０において、連絡先、カレンダー及びブックマークデータクラスに対するｓｙｎｃ−ｓｔａｒｔ応答及びｓｙｎｃ−ｃｈａｎｇｅｓ応答；連絡先及びブックマークに対するｓｙｎｃ−ｃｈａｎｇｅｓ応答；より多くの変化が保留中であることを指示するカレンダーに対するｓｙｎｃ−ｃｈａｎｇｅｓコマンド；及び連絡先及びブックマークに対するｓｙｎｃ−ｃｏｍｍｉｔコマンド；で応答する。これら２つのメッセージ２９３０及び２９４０は、第２のラウンドトリップを構成する。]
[0149] 第３のラウンドトリップは、連絡先、カレンダー及びブックマークに対するｓｙｎｃ−ｃｈａｎｇｅｓ応答を伴うクライアント装置からのメッセージ２９５０で始まる。このメッセージ２９５０は、連絡先及びブックマークに対するｓｙｎｃ−ｃｏｍｍｉｔ応答を含む。第３のラウンドトリップを完了するために、サーバー１２０は、データクラスに対するｓｙｎｃ−ｃｈａｎｇｅｓコマンド及びｓｙｎｃ−ｃｏｍｍｉｔコマンドを次のメッセージ２９６０においてクライアント装置１１０へ送信する。従って、３つのトランスポートプロトコルラウンドトリップだけで、複数のデータクラスの同期、同期モード再ネゴシエーション（カレンダーはサーバーにおいてリセットされた）、及び分割ｓｙｎｃ−ｃｈａｎｇｅｓ（サーバーからのカレンダー変化はメッセージ２９４０及びメッセージ２９６０において送信された）を完了することができる。]
[0150] クライアント装置１１０が、ｉｄｍａｐを伴うカレンダーに対するｓｙｎｃ−ｃｈａｎｇｅｓ応答、及びｓｙｎｃ−ｃｏｍｍｉｔ応答をサーバー１２０へ送信できるようにするために、任意の第４ラウンドトリップ２９７０を実施することができる。]
[0151] サーバー１２０は、全てのデータクラスがプル段階を完了する（即ち、第３メッセージを受信するとき）まで混合段階を遂行しない。これは、サーバー１２０が単一の同期ジョブにおいて全ての作業を遂行できるようにする。サーバーは、全てのデータクラスに対するクライアント１１０の全ての変化がサーバー１２０により受け取られるまで他のデータクラスに対するＳ＿ＮｏｔＣｏｍｐｌｅｔｅｄを送信する。]
[0152] Ｓｙｎｃ Ａｎｃｈｏｒチェックポイント
同期プロトコルは、追跡可能な同期セッションを編成して維持するためにコマンド及びコマンド応答に“ｓｙｎｃ ａｎｃｈｏｒｓ（同期アンカー）”を使用する。サーバー１２０は、その内部バージョニングメソッドに対してコマンド及びコマンド応答におけるアンカーを管理することができる。]
[0153] ｓｙｎｃ ａｎｃｈｏｒｓは、クライアント装置１１０及びサーバー１２０が同期プロセス中に交換する不透明なデータである。アンカーは、同期セッションの同期モードを決定するためにネゴシエーション段階中に交換することができる。次いで、コミット段階中に、アンカーの新たなセットを交換し、その後の同期セッション中に使用するように存続させることができる。比較として、他の同期プロトコルは、同期セッションの始めにアンカーを使用し、そしてアンカーは、同期セッションが首尾良く完了したときだけ更新されるか、或いはセッションがキャンセルされるか又は予期せず終了する場合にロールバックされる。]
[0154] ネゴシエーション中の予想されるアンカーと実際のアンカーとの食い違い（アンカー不一致として知られている）は、低速同期を生じさせるか、或いは最低でも、失敗した同期セッションからの全てのデータの再送信を生じさせる。信頼性のないデータネットワークでは、これは、全く進行が生じない状況を招き、サーバーとの同期は、外部条件が変化するまで同期を首尾良く完了することが実際上阻止される。予期せぬセッションの失敗も、次の同期セッションにおけるアンカー不一致を招くことになる。]
[0155] ＯＴＡ同期プロトコル１４０は、サーバー１２０が、同期セッション中に種々のチェックポイントにおいて更新されたアンカーを任意に返送できるようにする。“ａｎｃｈｏｒ”パラメータは、いかなる同期ファミリーコマンド又はコマンド応答にも存在する。チェックポイントアンカーは、“ｎｅｘｔ＿ｓｅｒｖｅｒ＿ａｎｃｈｏｒ”エレメントを含み、且つ“ｍｏｄｅ”エレメントを含む。これは、ｓｙｎｃ ａｎｃｈｏｒｓの微粒度更新を行って、アンカー不一致のおそれ及び影響を低減できるようにする。各サーバーアンカーは、アンカーが発生されたときの内部サーバー状態に関する正確な情報をサーバー１２０に与える情報でエンコードされる。例えば、サーバーアンカーは、クライアント装置１１０から要求された変化が中央データベースと混合されたかどうかの情報でエンコードすることができる。又、サーバーアンカーは、どの更新がクライアント装置１１０によって受け容れられたかの情報でエンコードすることもできる。更に、サーバーアンカーは、同期セッションが正常に完了したかどうかの情報でエンコードすることもできる。サーバーアンカーにおいて他の内部サーバー状態をエンコードすることもできる。]
[0156] 規範的なアンカーチェックポイントは、クライアント装置の最終的な“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドに応答して“ｅｎｄ ｏｆ ｓｅｒｖｅｒ ｍｉｎｇｌｅ ｐｈａｓｅ（サーバー混合段階の終了）”を含むことができる。又、アンカーチェックポイントは、とりわけ、分割“ｓｙｎｃ−ｃｈａｎｇｅｓ”及びコミット段階中のポイントを含むこともできる。]
[0157] サーバー１２０は、チェックポイントアンカーを追加するための時間及び位置をインテリジェントに判断することができる。チェックポイントアンカーは、それが“ｓｙｎｃ−ｃｈａｎｇｅｓ”コマンドに入れられたときには、受信したデータセットがデータクラススキーマのデータ完全性要件を守らせることを保証する。例えば、データ完全性要件は、チェックポイント付きのデータセットにおける未知のエンティティへの参照をもたせないことを含む。プル段階が完了した後に、最も最近のチェックポイントアンカーは、同期セッションがキャンセルされた場合でも、クライアント装置１１０によってセーブすることができる。]
[0158] 同期サーバー１２０は、チェックポイントアンカーを、それがもはや必要でないとき、或いはチェックポイント状態を維持するのに使用される関連サーバー側リソースをサーバーが解除する必要があるとき、満了とさせる。クライアント装置１１０が未知の又は満了となったチェックポイントアンカーを供給するときには、同期セッションが、依然、低速同期モードに入る。]
[0159] 次の同期セッションのネゴシエーション段階中、即ち“ｓｙｎｃ−ｓｔａｒｔ”コマンド中に、クライアント装置１１０は、その最後にセーブしたアンカーをサーバー１２０へ送信する。サーバー１２０は、手前の同期セッションが予期せず終了しても、又は“ｓｙｎｃ−ｃｏｍｍｉｔ”コマンド応答がサーバー１２０へ明確に返送されなくても、これらアンカーにエンコードされた情報を使用して、最も最近セーブされたチェックポイントから同期セッションをスタートさせる。クライアント装置１１０は、それが同期セッション中にそのようなアンカーを受け取ると、サーバーからの最も最近のアンカーを保持し、そして次の同期セッションに対する“ｓｙｎｃ−ｓｔａｒｔ”コマンドにおいて送信するためにその値をセーブする。]
[0160] 図３０は、チェックポイントアンカーを使用する規範的同期セッションを示す。クライアント装置１１０は、メッセージ３０１０を送信することにより同期セッションを開始する。クライアント装置１１０は、メッセージ３０１０にアンカー、ａ０を使用する。このアンカー、ａ０は、手前の同期セッションからの最後のサーバーアンカー値である。クライアント装置１１０及び同期サーバー１２０は、他のメッセージ３０２０、３０３０、３０４０、３０５０及び３０６０を必要に応じて交換する。同期セッション中の種々のポイントにおいて、同期サーバー１２０は、これらのメッセージ３０２０、３０３０、３０４０、３０５０及び３０６０を使用して、チェックポイントアンカーａ１、ａ２及びａ３を返送する。] 図３０
[0161] 同期サーバー１２０からの“ａｎｃｈｏｒｓ”エレメントを含む各メッセージを受信して処理すると、クライアント装置１１０は、そのアンカーを更新する。同期セッションが中断するか又はメッセージが失われると、クライアント装置は、それが首尾良く処理した最後のアンカーを次のセッションの“ｓｙｎｃ−ｓｔａｒｔ”コマンドにおいて供給する。どのアンカー値が受け取られるかに基づき、同期サーバー１２０は、必要に応じて手前の同期を完了させるためにどのアクションを取らねばならないか推測することができる。従って、非常に繊細なワイヤレスネットワークでも、又は大きなデータセットを送信する必要があるときでも、増分的な同期進行を行うことができる。]
[0162] 図３１は、規範的チェックポイントアンカーを示すテーブルである。このテーブルは、考えられるチェックポイントアンカー３１１０、それに関連した同期段階３１２０、及びチェックポイントアンカーに関連したサーバー状態３１３０を記述する列を含む。例えば、アンカーａ０は、サーバー状態に変化を生じさせないネゴシエーション段階を表すことができる。アンカーａ１は、プッシュ段階を表すことができる。サーバー１２０は、クライアント装置１１０により要求される変化を適用し、そしてサーバー１２０は、その変化のパート１をクライアント装置１１０へ送信する。アンカーａ２は、サーバー１２０により開始されるプッシュ段階を表す。サーバーは、その変化のパート２をクライアント装置１１０へ送信する。アンカーａ３は、コミット段階を表し、そして変化をコミットすることが完了したことを信号することができる。このアンカーは、同期セッションが完了したことを信号する。] 図３１
[0163] 装置の設定
同期プロトコル１２０は、サーバー１２０が装置設定及び能力を動的に要求するためのメカニズムをなす。“ｇｅｔ”及び“ｐｕｔ”コマンドは、情報を交換するのに使用される。いつでも、サーバー１２０は、例えば、装置設定及び能力を要求するために値“ｄｅｖｉｃｅｉｎｆｏ”をもつ“ｕｒｉ”パラメータと共に“ｇｅｔ”コマンドを送信する。或いは又、クライアント装置１１０は、同じ“ｕｒｉ”パラメータと共に“ｐｕｔ”コマンドをサーバー１２０へ送信する。“ｕｒｉ”パラメータの値は、種々のキー値対を含むディクショナリーである。“ｕｓｅｒｉｄ”の値は、それが存在するとき、認証原理を表し、ストリングとして実施される。“ａｕｔｈｔｙｐｅ”の値は、それが存在するとき、認証スキームを表し、ストリングとして実施される。“ａｕｔｈ”の値は、それが存在するとき、認証クレデンシャルを表し、ストリングとして表現される。受信者は、オペレーションを遂行しようとするときに、状態Ｓ＿ＯＫ（６００）のような成功状態を返送する。要求されたＵＲＩが未知であるときは、受信者は、ＵＲＩが見つからず未知であることを指示するために状態Ｅ＿ＮｏｔＦｏｕｎｄ（６０３）のような状態を返送する。要求されたオペレーションが許されず、例えば、許可された原理が、ＵＲＩを削除することが許されないときには、受信者は、要求されたオペレーションが許されないことを指示するために状態Ｅ＿ＮｏｔＡｌｌｏｗｅｄ（６０４）のような状態を返送する。供給されたデータが誤ったものであるために要求されたオペレーションを遂行できないときには、受信者は、要求されたオペレーションを遂行できないことを指示するために状態Ｅ＿ＢａｄＶａｌｕｅ（６０７）のような状態を返送する。供給された“ｉｔｅｍｔｙｐｅ”が誤ったものであるために要求されたオペレーションを遂行できないときには、受信者は、要求されたオペレーションがサポートされないことを指示するために状態Ｅ＿ＮｏｔＳｕｐｐｏｒｔｅｄ（６１４）のような状態を返送する。]
[0164] 図３２は、“ｕｒｉ”パラメータに対する規範的キー値対のテーブルを示す。“ｕｒｉ”パラメータに対する使用可能なキー３２１０は、ｖｅｒｓｉｏｎ（バージョン）、ｍｓｉｓｄｎ、ｄｅｖｉｃｅｉｄ、ｎａｍｅ（名前）、ｍｏｄｅｌ（モデル）、ｃａｒｒｉｒ（キャリア）及びｄａｔａｃｌａｓｓ（データクラス）を含む。ｖｅｒｓｉｏｎ、ｍｓｉｓｄｎ、ｄｅｖｉｃｅｉｄ、ｎａｍｅ、ｍｏｄｅｌ及びｃａｒｒｉｒキーに対する関連値３２２０は、ストリング値である。ｄａｔａｃｌａｓｓキーに対する値３２２０は、ディクショナリーである。又、このテーブルは、これらキーに対する関連記述３２３０も示している。例えば、ｖｅｒｓｉｏｎキー値は、バージョン１．１．４のような製品バージョンを記述することができる。ｍｓｉｓｄｎキー値は、現在インストールされたＳＩＭカードの電話番号を記述することができる。ｄｅｖｉｃｅｉｄキー値は、ＩＣＣＩＤを記述することができる。ｎａｍｅキー値は、ＥｃｔｏＰｈｏｎｅのようなユーザ装置名を記述することができる。ｍｏｄｅｌキー値は、クライアント装置１１０のモデル、例えば、ｉＰｈｏｎｅ（登録商標）、ｉＰｏｄ Ｔｏｕｃｈ（登録商標）、等を記述することができる。ｃａｒｒｉｒキー値は、ＡＴ＆Ｔ（登録商標）、Ｖｅｒｉｚｏｎ（登録商標）、等の電信会社を記述することができる。ｄａｔａｃｌａｓｓキー値は、データクラスを記述することができる。] 図３２
[0165] クライアント装置１１０が最初にサーバー１２０と同期するときには、サーバー１２０は、“ｇｅｔ”コマンドを送信することにより装置情報を要求する。その後、装置情報が変化したときに、クライアント装置１１０は、“ｐｕｔ”コマンドを送信することによりその変化した装置情報をサーバー１２０へ送信する。]
[0166] フィルタリング
フィルタリングは、クライアント装置１１０と同期したデータアイテムのセットを、データアイテムの値に基づいて限定する能力である。例えば、ユーザは、グループのあるセット内に含まれた連絡先のみと同期することを希望するか、現在日付の周りのある時間窓内のカレンダー事象と同期することを希望する。]
[0167] ｉＴｕｎｅｓ（登録商標）のようなデータ共有／管理アプリケーションでは、ｉＰｈｏｎｅ（登録商標）のようなクライアント装置１１０へ送られるデータアイテムのセットを限定又はフィルタリングするためにケーブル同期中にコンピュータによりフィルター設定が実施される。同期プロトコル１４０は、ワイヤレス同期解決策における同様のフィルタリング機能を与える。ｉＴｕｎｅｓ（登録商標）からの同じフィルター設定が、ユーザアクションを必要とせずに、サーバー１２０により実施される。従って、フィルタリングは、自動的に行うことができる。或いは又、実施されるべきフィルター設定をユーザが表示して編集できるようにするために、クライアント装置１１０におけるユーザインターフェイス（ＵＩ）をユーザに提示することもできる。]
[0168] 同期プロトコル１４０は、プリミティブコマンドを使用してクライアント装置１１０とサーバー１２０との間でフィルター設定を交換できるようにする。フィルターの情報は、“ｄａｔａｃｌａｓｓ／＜ｄａｔａｃｌａｓｓｎａｍｅ＞／ｆｉｌｔｅｒ”の形態の“ｕｒｉ”パラメータを使用して指定することができる。フィルター情報の値は、ディクショナリーである。]
[0169] 図３３は、フィルター設定に対する規範的なキー値を示すテーブルである。フィルター設定に対して使用可能なキー３３１０は、ｄｅｆａｕｌｔ＿ｃｏｎｔａｉｎｅｒ、ｃｏｎｓｔｒａｉｎ＿ｃｏｎｔａｉｎｅｒ及びｄｉｓｃａｒｄ＿ａｆｔｅｒ＿ｄａｙｓを含む。これらフィルター設定キーの値３３２０は、各々、ストリング、アレイ、及びストリングである。ｄｅｆａｕｌｔ＿ｃｏｎｔａｉｎｅｒキーのデータクラス１２０は、連絡先及びカレンダーを含む。又、ｃｏｎｓｔｒａｉｎ＿ｃｏｎｔａｉｎｅｒキーのデータクラス１２０は、連絡先及びカレンダーを含む。又、ｄｉｓｃａｒｄ＿ａｆｔｅｒ＿ｄａｙｓキーのデータクラス１２０は、カレンダーを含む。] 図３３
[0170] ｄｅｆａｕｌｔ＿ｃｏｎｔａｉｎｅｒキーは、連絡先に対するグループＩＤ及び事象に対するカレンダーＩＤのような、コンテナエンティティの識別（ＬＵＩＤ）を記述する。ｃｏｎｓｔｒａｉｎ＿ｃｏｎｔａｉｎｅｒキーは、含むべきグループのセットのような、含むべきコンテナエンティティのＬＵＩＤのセットを記述する。ｄｉｓｃａｒｄ＿ａｆｔｅｒ＿ｄａｙｓキーは、記述された日数より古い事象を削除しなければならないところの日数を記述する。]
[0171] 図３４は、擬似バッカス・ナウアフォーム（ＡＢＮＦ）のダイアグラムの一例である。擬似バッカス・ナウアフォームは、シンタックスを記述する便利な仕方である。ＢＮＦは、文脈自由文法を表現できるメタシンタックスである。文脈自由文法は、語彙ルール及び構文ルールの２組のルールを使用することによってプログラミング言語のシンタックスを定義することができる。増強型ＢＮＦは、異なる命名ルール、繰り返し、代替、順序独立性、及び値範囲を使用するＢＮＦの変更バージョンである。] 図３４
[0172] 図３５は、規範的な同期セッションを示す。図３５に示す規範的な同期セッションは、分割同期変化及びプットフィルター情報を含む。クライアント装置１１０は、ネゴシエーション段階コマンド（“ｓｙｎｃ−ｓｔａｒｔ”）及びプル段階コマンド（“ｓｙｎｃ−ｃｈａｎｇｅｓ”）を第１メッセージ３５１０においてサーバー１２０へ送信する。プットコマンドは、特定のデータクラスに対するデータアイテムを送信するのに使用される。図３５に示す例では、プットコマンドで指示されたデータクラスは、連絡先である。又、データアイテムは、データをデータクラスに対して同期されるものに限定するようフィルタリングされる。] 図３５
[0173] 第２メッセージ３５２０において、サーバー１２０は、連絡先データクラスに対しネゴシエーションの成功を指示するために状態“Ｓ＿ＯＫ”と共にｓｙｎｃ−ｓｔａｒｔコマンド応答を送信することにより応答する。更に、アンカーを使用してチェックポイントを指示する。又、サーバー１２０は、データクラスに対する全ての適当なデータアイテムがコマンドパラメータに含まれるのではないことを指示する“ｍｏｒｅ”ブーリアンフラグと共に連絡先データクラスに対するｓｙｎｃ−ｃｈａｎｇｅｓコマンドを送信する。更に、第２メッセージ３５２０は、プットの成功を指示するために“Ｓ＿ＯＫ”状態と共にプットコマンド応答を含むことができる。]
[0174] 第３メッセージ３５３０において、クライアント装置１１０は、ｕｒｉパラメータにより指示された連絡先データベースに対して“Ｓ＿ＯＫ”状態と共にｓｙｎｃ−ｃｈａｎｇｅｓコマンド応答を含む。又、例えば、ＧＵＩＤ＿ＬＵＩＤマッピングを与えるために、ｉｄｍａｐも含まれる。第４メッセージ３５４０において、サーバー１２０は、連絡先データクラスを指示するためにｕｒｉパラメータと共にｓｙｎｃ−ｃｈａｎｇｅｓコマンドを送信する。又、より多くのデータが続くことを指示するために“ｍｏｒｅ”ブーリアンが含まれる。第５メッセージ３５５０では、クライアント装置１１０は、連絡先データクラスに対する更新の成功を指示するために“Ｓ＿ＯＫ”状態と共にｓｙｎｃ−ｃｈａｎｇｅｓコマンド応答を送信する。第６メッセージ３５６０において、サーバー１２０は、連絡先データクラスに対してｓｙｎｃ−ｃｈａｎｇｅｓコマンド及びｓｙｎｃ−ｃｏｍｍｉｔコマンドを送信する。クライアント装置１１０は、第７メッセージ３５７０において、更新の成功を指示するためにｓｙｎｃ−ｃｈａｎｇｅｓコマンド応答で応答する。又、クライアント装置１１０は、クライアント装置が変化をコミットしたことを指示するためにｓｙｎｃ−ｃｏｍｍｉｔ応答（ＯＫ）も含む。最後のメッセージ３５８０は、同期セッションの最終メッセージを指示するために空きメッセージ本体を有する。]
[0175] 図３６、３７ａ、３７ｂ、３８ａ、３８ｂ、３８ｃ、３８ｄ、３９ａ、３９ｂ、３９ｃ、４０ａ及び４０ｂは、同期セッションに対するワイヤトレース例を示す。図３６は、リセット同期セッションに対する４つの規範的メッセージの概要を示す。図３７ａ及び３７ｂは、クライアント装置１１０からサーバー１２０へ送られる規範的メッセージを示す。ｓｙｎｃ−ｓｔａｒｔコマンドは、データクラスを示す値“ｃｏｍ．ａｐｐｌｅ．Ｃｏｎｔａｃｔｓ”と共にｕｒｉパラメータを含む。又、同期モードは、“ｒｅｓｅｔ”として指示される。又、メッセージは、同じデータクラス（ｃｏｍ．ａｐｐｌｅ．Ｃｏｎｔａｃｔｓ）及び空き変化と共にｓｙｎｃ−ｃｈａｎｇｅｓコマンドを含む。] 図３６ 図３７ａ

权利要求:

請求項1
データを同期する方法において、同期セッションを開始する要求を受け取るステップであって、その要求は、１つ以上のデータクラスの各々に対する提案された同期モード、及び１つ以上のデータクラスへの１つ以上の変化、を含むものであるステップと、各データクラスに対する提案された同期モードが受け容れられるかどうか指示するための１つ以上の状態コードを発生するステップと、前記発生された状態コードに基づき、各データクラスに対する前記受け容れられた同期モードを使用して、１つ以上のデータクラスへの１つ以上の変化に関連した１つ以上のデータアイテムを選択的に更新するステップと、前記更新された１つ以上のデータアイテムをサーバーにおいて選択的にコミットするステップと、を備えた方法。
請求項2
１つ以上の状態コードを発生する前記ステップは、以前の同期セッションからセーブされた情報にアクセスして、１つ以上のデータアイテムを同期するのにその提案された同期モードを使用すべきかどうか決定することを含む、請求項１に記載の方法。
請求項3
要求を受け取る前記ステップは、２つ以上のデータクラスに対する提案された同期モードをパラレルに受け取ることを含む、請求項１に記載の方法。
請求項4
要求を受け取る前記ステップは、高速同期モード、低速同期モード又はリセット同期モードを含む提案された同期モードを受け取ることを含む、請求項１に記載の方法。
請求項5
要求を受け取る前記ステップは、更新されるべきデータアイテムの交換だけを可能にする高速同期モードを含む提案された同期モードを受け取ることを含む、請求項１に記載の方法。
請求項6
同期セッションが中断した後に、高速同期モードを再受け容れするステップを更に備えた、請求項５に記載の方法。
請求項7
同期セッションを、２つのメッセージを含む１つのラウンドトリップで完了するステップを更に備えた、請求項１に記載の方法。
請求項8
要求を受け取る前記ステップは、前記提案された同期モード、及び１つ以上のデータクラスへの１つ以上の変化を、クライアント装置からの単一のメッセージで受け取る、ことを含む請求項１に記載の方法。
請求項9
選択的にコミットする前記ステップは、前記更新された１つ以上のデータアイテムをコミットするコマンドをクライアント装置が送信するときに、前記更新された１つ以上のデータアイテムをサーバーにおいて選択的にコミットする、ことを含む請求項１に記載の方法。
請求項10
前記提案された同期モードを拒絶するステップと、異なる同期モードで要求に応答するステップと、を更に備えた請求項１に記載の方法。
請求項11
コンピュータ読み取り可能な媒体において実施されるコンピュータプログラム製品であって、データ処理装置が、同期セッションを開始する要求を受け取り、その要求は、１つ以上のデータクラスの各々に対する提案された同期モード、及び１つ以上のデータクラスへの１つ以上の変化、を含むものであり、各データクラスに対する提案された同期モードが受け容れられるかどうかを表す状態コードを発生し、その発生された状態コードに基づき、各データクラスに対する受け容れられた同期モードを使用して、１つ以上のデータクラスへの１つ以上の変化に関連した１つ以上のデータアイテムを選択的に更新し、その更新された１つ以上のデータアイテムをデータレポジトリーにおいて選択的にコミットする、ことを含むオペレーションを遂行するようにさせるよう動作できるコンピュータプログラム製品。
請求項12
更に、データ処理装置が、以前の同期セッションからセーブされた情報にアクセスして、１つ以上の状態コードを発生するようにさせるよう動作できる、請求項１１に記載のコンピュータプログラム製品。
請求項13
更に、データ処理装置が、２つ以上のデータクラスに対する提案された同期モードをパラレルに受け取るようにさせるよう動作できる、請求項１１に記載のコンピュータプログラム製品。
請求項14
更に、データ処理装置が、高速同期モード、低速同期モード又はリセット同期モードを含む提案された同期モードを受け取るようにさせるよう動作できる、請求項１１に記載のコンピュータプログラム製品。
請求項15
更に、データ処理装置が、更新されるべきデータアイテムの交換のみを可能にする高速同期モードを含む提案された同期モードを受け取るようにさせるよう動作できる、請求項１１に記載のコンピュータプログラム製品。
請求項16
同期セッションが中断されたときに高速同期モードを再開することを更に含む、請求項１５に記載のコンピュータプログラム製品。
請求項17
更に、データ処理装置が、２つのメッセージを含む１つのラウンドトリップで同期セッションを完了するようにさせるよう動作できる、請求項１１に記載のコンピュータプログラム製品。
請求項18
更に、データ処理装置が、提案された同期モード及び１つ以上のデータクラスへの１つ以上の変化をクライアント装置からの単一のメッセージで受け取るようにさせるよう動作できる、請求項１１に記載のコンピュータプログラム製品。
請求項19
更に、データ処理装置が、更新された１つ以上のデータアイテムをコミットするコマンドをクライアント装置が送信するときに、更新された１つ以上のデータアイテムをサーバーにおいて選択的にコミットするようにさせるよう動作できる、請求項１１に記載のコンピュータプログラム製品。
請求項20
更に、データ処理装置が、提案された同期モードを拒絶し、及び前記要求に異なる同期モードで応答する、ことを含むオペレーションを遂行するようにさせるよう動作できる、請求項１１に記載のコンピュータプログラム製品。
請求項21
同期サーバーにおいて、１つ以上のクライアント装置への１つ以上の接続をオープンすることのできるトランスポートプロトコル、及びそのオープンされた１つ以上の接続を経て前記サーバーと１つ以上のクライアント装置との間のデータ同期を可能にする同期プロトコル、を動作するよう構成されたプロセッサを備え、前記同期プロトコルは、前記サーバーが、同期セッションを開始する要求を受け取れるようにし、この要求は、１つ以上のデータクラスの各々に対する提案された同期モードと、１つ以上のデータクラスへの１つ以上の変化とを含むものであり、更に、各データクラスに対する提案された同期モードが受け容れられるかどうか指示するための１つ以上の状態コードを発生し、前記発生された状態コードに基づいて、各データベースに対する受け容れられた同期モードを使用して、１つ以上のデータクラスへの１つ以上の変化に関連した１つ以上のデータアイテムを選択的に更新し、前記更新された１つ以上のデータアイテムを選択的にコミットする、ことができるようにするものである、サーバー。
請求項22
前記プロセッサは、受け取られた１つ以上の変化に基づいて１つ以上のデータアイテムを更新するためにデータレポジトリーにアクセスするように構成される、請求項２１に記載のサーバー。
請求項23
前記プロセッサは、各データクラスに対する提案された同期モードを、以前の同期セッションからセーブされた情報に基づいて受け容れ又は拒絶するように同期プロトコルを動作するよう構成される、請求項２１に記載のサーバー。
請求項24
前記プロセッサは、２つ以上のデータクラスに対する提案された同期モードをパラレルに受け取るように同期プロトコルを動作するよう構成される、請求項２１に記載のサーバー。
請求項25
前記プロセッサは、高速同期モード、低速同期モード又はリセット同期モードを含む提案された同期モードを受け取るように同期プロトコルを動作するよう構成される、請求項２１に記載のサーバー。
請求項26
前記プロセッサは、更新されるべきデータアイテムだけを１つ以上のクライアント装置が送信できるようにする高速同期モードを含む提案された同期モードを受け取るように同期プロトコルを動作するよう構成される、請求項２１に記載のサーバー。
請求項27
前記プロセッサは、同期セッションが中断されたときに高速同期を再開する要求を受け取るように同期プロトコルを動作するよう構成される、請求項２６に記載のサーバー。
請求項28
前記プロセッサは、２つのメッセージを含む１つのラウンドトリップで同期セッションを完了するように同期プロトコルを動作するよう構成される、請求項２１に記載のサーバー。
請求項29
前記プロセッサは、提案された同期モード及び１つ以上のデータクラスへの１つ以上の変化を、１つ以上のクライアント装置のうちの少なくとも１つからの単一のメッセージで受け取るように、同期プロトコルを動作するよう構成される、請求項２１に記載のサーバー。
請求項30
前記プロセッサは、１つ以上のクライアント装置のうちの１つが、更新された１つ以上のデータアイテムをコミットするコマンドを送信するときに、更新された１つ以上のデータアイテムをサーバーにおいて選択的にコミットするように、同期プロトコルを動作するよう構成される、請求項２１に記載のサーバー。
請求項31
前記プロセッサは、提案された同期モードを拒絶し、及び異なる同期モードで要求に応答する、ように同期プロトコルを動作するよう構成される、請求項２１に記載のサーバー。
請求項32
データを同期する方法において、同期セッションを開始するためにサーバーへ要求を送信するステップであって、その要求は、１つ以上のデータクラスの各々に対する提案された同期モード、及び１つ以上のデータクラスへの１つ以上の変化、を含むものであるステップと、各データクラスに対する提案された同期モードがサーバーにより受け容れられたかどうか指示する１つ以上の同期コードを受け取るステップと、その受け取られた状態コードに基づいて、受け容れられた同期モードを使用して、１つ以上のデータクラスへの付加的な変化をサーバーから受け取るステップと、クライアント装置において、サーバーから受け取られた付加的な変化をコミットするステップと、を備えた方法。
請求項33
１つ以上のデータクラスのうちの少なくとも１つに対する提案された同期モードがサーバーにより拒絶されたことを指示する１つ以上の状態コードを受け取るステップと、前記拒絶された同期モードとは異なる同期モードを含む別の要求を送信するステップと、を更に備えた請求項３２に記載の方法。
請求項34
前記提案された同期モード及び１つ以上の変化を単一のメッセージにおいてサーバーへ送信するステップを更に備えた、請求項３２に記載の方法。
請求項35
２つ以上のデータクラスに対する提案された同期モードをパラレルに送信するステップを更に備えた、請求項３２に記載の方法。
請求項36
２つ以上のデータクラスに対する提案された同期モードをパラレルに送信する前記ステップは、２つ以上のデータクラスの各々に対して異なる提案された同期モードをパラレルに送信することを含む、請求項３５に記載の方法。
請求項37
２つ以上のデータクラスの各々に対して異なる提案された同期モードをパラレルに送信することは、１つのデータクラスに対して提案された高速同期モードを送信し、そして別のデータクラスに対して提案された低速同期モードを送信することを含む、請求項３５に記載の方法。
請求項38
同期セッションが中断された後に、受け容れられた同期プロトコルを使用して同期セッションを再開するステップを更に備えた、請求項３２に記載の方法。
請求項39
コンピュータ読み取り可能な媒体において実施されるコンピュータプログラム製品であって、データ処理装置が、同期セッションを開始する要求をサーバーへ送信し、その要求は、１つ以上のデータクラスの各々に対する提案された同期モードと、１つ以上のデータクラスへの１つ以上の変化とを含むものであり、更に、各データクラスに対する提案された同期モードがサーバーにより受け容れられるかどうかを表す１つ以上の状態コードを受け取り、前記受け取った状態コードに基づき、前記受け容れられた同期モードを使用して、１つ以上のデータクラスへの付加的な変化をサーバーから受け取り、前記サーバーから受け取ったその付加的な変化をクライアント装置においてコミットする、ことを含む１つ以上のオペレーションを遂行するようにさせるよう動作できる、コンピュータプログラム製品。
請求項40
更に、データ処理装置が、１つ以上のデータクラスのうちの少なくとも１つに対する提案された同期モードがサーバーにより拒絶されたことを指示する１つ以上の状態コードを受け取り、その拒絶された同期モードとは異なる同期モードを含む別の要求を送信する、ことを含むオペレーションを遂行するようにさせるよう動作できる、請求項３９に記載のコンピュータプログラム製品。
請求項41
更に、データ処理装置が、提案された同期モード及び１つ以上の変化を単一のメッセージにおいてサーバーへ送信するようにさせるよう動作できる、請求項３９に記載のコンピュータプログラム製品。
請求項42
更に、データ処理装置が、２つ以上のデータクラスに対する提案された同期モードをパラレルに送信するようにさせるよう動作できる、請求項３９に記載のコンピュータプログラム製品。
請求項43
更に、データ処理装置が、２つ以上のデータクラスの各々に対する異なる提案された同期モードをパラレルに送信するようにさせるよう動作できる、請求項４２に記載のコンピュータプログラム製品。
請求項44
更に、データ処理装置が、１つのデータクラスに対して提案された高速同期モードをそして別のデータクラスに対して提案された低速同期モードを送信させるよう動作できる、請求項４２に記載のコンピュータプログラム製品。
請求項45
更に、データ処理装置が、同期セッションが中断された後に、受け容れられた同期プロトコルを使用して同期セッションを再開するようにさせるよう動作できる、請求項３９に記載のコンピュータプログラム製品。
請求項46
クライアント装置において、サーバーへの１つ以上の接続をオープンすることのできるトランスポートプロトコル、及びそのオープンされた１つ以上の接続を経て前記クライアント装置と前記サーバーとの間のデータ同期を可能にする同期プロトコル、を動作するように構成されたプロセッサを備え、前記同期プロトコルは、前記クライアント装置が、同期セッションを開始する要求をサーバーへ送信し、その要求は、１つ以上のデータクラスの各々に対する提案された同期モードと、１つ以上のデータクラスへの１つ以上の変化とを含むものであり、更に、各データクラスに対する提案された同期モードがサーバーによって受け容れられたかどうかを表す１つ以上の状態コードを受け取り、その受け取った状態コードに基づいて、その受け容れられた同期モードを使用して、１つ以上のデータクラスへの付加的な変化をサーバーから受け取り、サーバーから受け取った付加的な変化をクライアント装置においてコミットする、ことができるようにする、クライアント装置。
請求項47
前記プロセッサは、１つ以上のデータクラスのうちの少なくとも１つに対する提案された同期モードがサーバーにより拒絶されたことを指示する１つ以上の状態コードを受け取り、その拒絶された同期モードとは異なる同期モードを含む別の要求を送信する、ように前記同期プロトコルを動作するよう構成される、請求項４６に記載のクライアント装置。
請求項48
前記プロセッサは、提案された同期モード及び１つ以上の変化を単一のメッセージにおいてサーバーへ送信するように前記同期プロトコルを動作するよう構成される、請求項４６に記載のクライアント装置。
請求項49
前記プロセッサは、２つ以上のデータクラスに対する提案された同期モードをパラレルに送信するように前記同期プロトコルを動作するよう構成される、請求項４６に記載のクライアント装置。
請求項50
前記プロセッサは、２つ以上のデータクラスの各々に対して異なる提案された同期モードをパラレルに送信することを含めて、２つ以上のデータクラスに対する提案された同期モードをパラレルに送信するように前記同期プロトコルを動作するよう構成される、請求項４９に記載のクライアント装置。
請求項51
前記プロセッサは、１つのデータクラスに対して提案された高速同期モードをそして別のデータクラスに対して提案された低速同期モードを送信するように前記同期プロトコルを動作するよう構成される、請求項４９に記載のクライアント装置。
請求項52
前記プロセッサは、同期セッションが中断された後に、受け容れられた同期プロトコルを使用して同期セッションを再開するように同期プロトコルを動作するよう構成される、請求項４９に記載のクライアント装置。